fix(adr): custom styling adr name

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