Add 12 ADRs documenting frontend architecture decisions

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

@@ -0,0 +1,30 @@
+# ADR 0006: Data Loading via Route Resolvers
+
+**Date:** 2026-04-26
+**Status:** Accepted
+
+## Context
+
+Route components need data to render. Two common approaches exist:
+
+- **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`.
+
+Loading states scattered across every component lead to inconsistent UX and duplicate skeleton/spinner logic.
+
+## Decision
+
+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`.
+
+Data is accessed in components via:
+
+```ts
+this.route.data.subscribe((data) => { ... });
+```
+
+## 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.