docs(adr): convert all ADRs to MADR 2.1.2 format

Rewrites all 12 frontend ADRs from a custom structure to the MADR 2.1.2
template required by the VS Code ADR Manager extension: bullet metadata
(Status/Date), standardised section headings, "Chosen option: X, because Y"
wording, and explicit Pros/Cons blocks per option.

docs/decisions/0006-data-loading-via-route-resolvers.md

@@ -1,30 +1,42 @@
-# ADR 0006: Data Loading via Route Resolvers
+# Pre-fetch route data using Angular route resolvers
 
-**Date:** 2026-04-26
-**Status:** Accepted
+- Status: accepted
+- Date: 2026-04-26
 
-## Context
+## Context and Problem Statement
 
-Route components need data to render. Two common approaches exist:
+Route components need data to render. Should that data be fetched before the route activates (resolver) or after the component renders (in-component)?
 
-- **In-component fetching** (`ngOnInit`): component renders first in a loading state, then fetches data asynchronously.
-- **Route resolvers**: data is fetched before the route activates; the component receives it immediately via `ActivatedRoute.data`.
+## Considered Options
 
-Loading states scattered across every component lead to inconsistent UX and duplicate skeleton/spinner logic.
+- Angular route resolvers
+- In-component fetching (ngOnInit)
 
-## Decision
+## Decision Outcome
 
-Use Angular route resolvers (under `src/app/core/resolvers/`) to pre-fetch data for each route. New route components should follow this pattern rather than fetching in `ngOnInit`.
+Chosen option: "Angular route resolvers", because components receive data immediately via `ActivatedRoute.data`, eliminating the need for per-component loading states on initial render.
 
-Data is accessed in components via:
+### Positive Consequences
 
-```ts
-this.route.data.subscribe((data) => { ... });
-```
+- No loading state needed in components for the initial data fetch.
+- Loading indication can be centralised at the router level via router events.
+- Data availability is guaranteed before any component lifecycle hook runs.
 
-## Consequences
+### Negative Consequences
 
-- **Positive:** Components have their data available immediately — no need for per-component loading states on initial render.
-- **Positive:** Loading indication is centralised at the router level (can use router events to show a global progress bar).
-- **Negative:** Navigation appears "stuck" while the resolver fetches — there is no partial render before data arrives. Acceptable given the API response times in this application.
-- **Constraint:** Resolvers should handle errors gracefully (redirect or return a default value) to avoid navigation hangs on API failure.
+- Navigation appears paused while the resolver fetches — there is no partial render before data arrives.
+- Resolver errors must be handled explicitly to avoid navigation hangs on API failure.
+
+## Pros and Cons of the Options
+
+### Angular route resolvers
+
+- Good, because data is available immediately in the component.
+- Good, because loading logic is centralised outside the component.
+- Bad, because navigation is blocked until the resolver completes.
+
+### In-component fetching (ngOnInit)
+
+- Good, because navigation is instant — component renders immediately.
+- Bad, because each component must manage its own loading and error states.
+- Bad, because inconsistent UX across routes if not implemented uniformly.