[Fix] Custom styling ADR file metadata (#20)

## What does this change?

There was somthing wrong with the metadata for "API for custom styling"
ADR, where vscode and storybook was unable to recognise it.

I've somehow managed to fix the issue, despite not knowing what the
issue was, and apply formatting.

Author: coldlink

…ision-records/2026-02-custom-styling.md …cision-records/2026-02-custom-styling.mddocs/decision-records/2026-02-custom-styling.md renamed to docs/decision-records/2026-02-custom-styling.md docs/decision-records/2026-02-custom-styling.md renamed to docs/decision-records/2026-02-custom-styling.md

@@ -12,24 +12,24 @@ We are confident Stand users will want to customise Stand components to some deg
 
 ## Options
 
-1. No APIs. Stand consumers all use the same visual presentation.  
-   - Stand consumers cannot easily adapt colours to match existing tooling  
-   - Stand consumers cannot easily apply layout styling to components  
-   - If users apply arbitrary theming, there’s no API contract that guarantees compatibility with future updates  
-2. Theming API. Stand consumers can apply some styling options via a typesafe API, determined by the component, as an easy way to override anticipated or commonly used styling features, e.g. colors.  
-   - Stand consumers can adapt commonly used styling to match existing tooling  
-   - Stand consumers cannot easily apply layout styling to components  
-   - Users can update Stand with confidence that breaking changes will be caught by the compiler  
-3. CSS overrides API	  
-   - Stand consumers can adapt commonly used styling to match existing tooling — but we’d prefer them to use a typesafe API for that, where possible  
-   - Stand consumers can apply arbitrary styling to components, targeting that specific component. An example use-case would be adding \`margin-left: auto\` to ensure that a particular element is right-aligned in a flex context  
-   - There’s no guarantee the library can make to prevent breaking changes across any semantic version — patch changes could refactor component structure, for example  
-4. Classname overrides API  
-   - Stand consumers can apply a classname to component instances, and style accordingly by adding stylesheets to the document  
-   - There’s no guarantee the library can make to prevent breaking changes across any semantic version, as with CSS overrides  
-5. Static classnames for components  
-   - Stand consumers can style components by targeting the classname owned by that component  
-   - There’s no guarantee the library can make to prevent breaking changes across any semantic version, as with CSS overrides  
+1. No APIs. Stand consumers all use the same visual presentation.
+   - Stand consumers cannot easily adapt colours to match existing tooling
+   - Stand consumers cannot easily apply layout styling to components
+   - If users apply arbitrary theming, there’s no API contract that guarantees compatibility with future updates
+2. Theming API. Stand consumers can apply some styling options via a typesafe API, determined by the component, as an easy way to override anticipated or commonly used styling features, e.g. colors.
+   - Stand consumers can adapt commonly used styling to match existing tooling
+   - Stand consumers cannot easily apply layout styling to components
+   - Users can update Stand with confidence that breaking changes will be caught by the compiler
+3. CSS overrides API
+   - Stand consumers can adapt commonly used styling to match existing tooling — but we’d prefer them to use a typesafe API for that, where possible
+   - Stand consumers can apply arbitrary styling to components, targeting that specific component. An example use-case would be adding \`margin-left: auto\` to ensure that a particular element is right-aligned in a flex context
+   - There’s no guarantee the library can make to prevent breaking changes across any semantic version — patch changes could refactor component structure, for example
+4. Classname overrides API
+   - Stand consumers can apply a classname to component instances, and style accordingly by adding stylesheets to the document
+   - There’s no guarantee the library can make to prevent breaking changes across any semantic version, as with CSS overrides
+5. Static classnames for components
+   - Stand consumers can style components by targeting the classname owned by that component
+   - There’s no guarantee the library can make to prevent breaking changes across any semantic version, as with CSS overrides
    - There’s no way to target a particular instance of a component with this API
 
 ## Decision
@@ -46,5 +46,5 @@ Unlike in source, we think the less stringent styling requirements in our toolin
 
 ## Consequences
 
-- We should adopt 2.) and 3.)  
+- We should adopt 2.) and 3.)
 - We should document the use-cases for each API, with a warning about usage that might expose the user to breaking changes