[repo] Update to respect strict admonitions

This change is required for Docusaurus 3.10

https://docusaurus.io/blog/releases/3.10#strict-admonitions

Author: andrewnicols

docs/apis/_files/db-access-php.mdx

@@ -4,7 +4,7 @@ The `db/access.php` file contains the __initial__ configuration for a plugin's a
 
 Access control is handled in Moodle by the use of Roles, and Capabilities. You can read more about these in the [Access API](../subsystems/access.md) documentation.
 
-:::caution Changing initial configuration
+:::caution[Changing initial configuration]
 
 If you make changes to the initial configuration of _existing_ access control rules, these will only take effect for _new installations of your plugin_. Any existing installation **will not** be updated with the latest configuration.
 

docs/apis/_files/db-events-php.mdx

@@ -5,7 +5,7 @@ The `db/events.php` file allows you define any event subscriptions that your plu
 
 Event subscriptions are a convenient way to observe events generated elsewhere in Moodle.
 
-:::caution Communication between components
+:::caution[Communication between components]
 
 You _should not_ use event subscriptions to subscribe to events belonging to other plugins, without defining a dependency upon that plugin.
 

docs/apis/_files/db-tasks-php.mdx

@@ -2,7 +2,7 @@
 
 The `db/tasks.php` file contains the initial schedule configuration for each of your plugins _scheduled_ tasks. Adhoc tasks are not run on a regular schedule and therefore are not described in this file.
 
-:::caution Editing the schedule for an existing task
+:::caution[Editing the schedule for an existing task]
 
 If an existing task is edited, it will only be updated in the database if the administrator has not customised the schedule of that task in any way.
 

docs/apis/_files/db-upgrade-php.mdx

@@ -3,7 +3,7 @@ The `db/upgrade.php` file contains upgrade steps, including database schema chan
 
 See the [Upgrade API](../../guides/upgrade/index.md) documentation for further information.
 
-:::danger Generating Database Schema changes
+:::danger[Generating Database Schema changes]
 
 When making changes to the database schema you **must** use the build-in [XMLDB editor](https://docs.moodle.org/dev/XMLDB_Documentation) within
 Moodle. This can be used to generate php upgrade steps.

docs/apis/_files/lang-extra.md

@@ -1,6 +1,6 @@
 {/* <!-- markdownlint-disable MD041 --> */}
 
-:::caution Activity modules are different
+:::caution[Activity modules are different]
 
 Activity modules do not use the __frankenstyle__ name as a filename, they use the plugin name. For example the forum activity plugin:
 

docs/apis/_files/lib.mdx

@@ -4,7 +4,7 @@ The `lib.php` file is a legacy file which acts as a bridge between Moodle core,
 
 All functions defined in this file **must** meet the requirements set out in the relevant section of the [Coding style](/general/development/policies/codingstyle#functions-and-methods).
 
-:::note Performance impact
+:::note[Performance impact]
 
 Moodle core often loads all the <tt>lib.php</tt> files of a given plugin types. For performance reasons, it is strongly recommended to keep this file as small as possible and have just required code implemented in it. All the plugin's internal logic should be implemented in the auto-loaded classes.
 

docs/apis/_files/locallib.mdx

@@ -1,7 +1,7 @@
 {/* <!-- markdownlint-disable first-line-heading --> */}
 {/* <!-- cspell:ignore locallib --> */}
 
-:::caution Legacy feature
+:::caution[Legacy feature]
 
 The use of this file is no longer recommended, and new uses of it will not be permitted in core code.
 

docs/apis/_files/styles-css.mdx

@@ -4,7 +4,7 @@ Plugins may define a '/styles.css' to provide plugin-specific styling. See the f
 - [Plugin contribution checklist#CSS styles](/general/community/plugincontribution/checklist#css-styles)
 - [CSS Coding Style](https://docs.moodle.org/dev/CSS_Coding_Style)
 
-:::tip Avoid custom styles where possible
+:::tip[Avoid custom styles where possible]
 
 Rather than writing custom CSS for your plugin, where possible apply Bootstrap classes to the DOM elements in your output. These will be easier to maintain and will adopt most colour, branding, and other customisations applied to a theme.
 

docs/apis/_files/thirdpartylibs-xml.mdx

@@ -5,7 +5,7 @@ This information is used to generate ignore file configuration for linting tools
 
 Within the XML the `location` is a file, or directory, relative to your plugin's root.
 
-:::caution Licensing
+:::caution[Licensing]
 
 The license of any third-party code included in your plugin, and within the `thirdpartylibs.xml` file **must** be [compatible with the GNU GPLv3](http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses).
 

docs/apis/_files/upgrade-php.mdx

@@ -3,7 +3,7 @@ The `db/upgrade.php` file contains upgrade steps, including database schema chan
 
 See the [Upgrade API](../../guides/upgrade/index.md) documentation for further information.
 
-:::danger Generating Database Schema changes
+:::danger[Generating Database Schema changes]
 
 When making changes to the database schema you **must** use the build-in [XMLDB editor](https://docs.moodle.org/dev/XMLDB_Documentation) within
 Moodle. This can be used to generate php upgrade steps.