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/0002-standalone-components-no-ngmodules.md

@@ -1,20 +1,42 @@
-# ADR 0002: Standalone Components Without NgModules
+# Use Angular standalone components without NgModules
 
-**Date:** 2026-04-26
-**Status:** Accepted
+- Status: accepted
+- Date: 2026-04-26
 
-## Context
+## Context and Problem Statement
 
-Historically, Angular required all components, directives, and pipes to be declared inside NgModules, which acted as compilation units. Angular 14 introduced standalone components as an opt-in alternative. Angular 17+ made them the recommended default and they became the foundation of the new `@angular/build:application` builder.
+Angular historically required all components, directives, and pipes to be declared inside NgModules. Angular 14 introduced standalone components as an opt-in. Angular 17+ made them the recommended default and they are required for the esbuild-based application builder. How should the application be structured?
 
-## Decision
+## Considered Options
 
-The entire application uses standalone components with no NgModules. The app entry point is `app.config.ts` (providers) + `app.routes.ts` (routing), with no `AppModule`.
+- Standalone components (no NgModules)
+- NgModule-based architecture
 
-## Consequences
+## Decision Outcome
 
-- **Positive:** Each component explicitly declares its own `imports`, making dependencies visible and reducing hidden coupling.
-- **Positive:** Better tree-shaking — unused imports in one component don't affect others.
-- **Positive:** Aligns with Angular's long-term direction; compatible with the esbuild-based application builder.
-- **Negative:** Slightly more verbose component decorators (each must list its own `imports`).
-- **Note:** `CommonModule` should not be imported wholesale; use specific primitives (`NgClass`, `DatePipe`, etc.) or the newer `@if`/`@for` control flow syntax instead.
+Chosen option: "Standalone components (no NgModules)", because they are the Angular-recommended default since v17, provide explicit per-component dependency declarations, and are required for the esbuild application builder.
+
+### Positive Consequences
+
+- Each component explicitly declares its own `imports` — dependencies are visible and not hidden in a shared module.
+- Better tree-shaking: unused imports in one component don't affect others.
+- Aligns with Angular's long-term direction.
+
+### Negative Consequences
+
+- Slightly more verbose component decorators — each component lists its own imports rather than inheriting from a module.
+
+## Pros and Cons of the Options
+
+### Standalone components (no NgModules)
+
+- Good, because explicit dependency declarations per component.
+- Good, because required for the esbuild application builder.
+- Good, because Angular-recommended default since v17.
+- Bad, because more verbose decorators.
+
+### NgModule-based architecture
+
+- Good, because familiar pattern for developers coming from Angular < 14.
+- Bad, because deprecated direction; incompatible with the modern application builder.
+- Bad, because shared module patterns hide dependencies.