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/0010-node-version-management-nvm.md

@@ -1,19 +1,51 @@
-# ADR 0010: Node Version Management with nvm and .nvmrc
+# Pin Node version with nvm and .nvmrc
 
-**Date:** 2026-04-26
-**Status:** Accepted
+- Status: accepted
+- Date: 2026-04-26
 
-## Context
+## Context and Problem Statement
 
-Angular 21 requires Node.js >= 20.19 or >= 22.12. The system Node version on a development machine may not meet this requirement, causing silent build failures or CLI errors.
+Angular 18 requires Node.js `^18.19.1 || ^20.11.1`. The system Node version on a development machine may not meet this requirement, causing silent build failures or CLI errors. How should the required Node version be enforced?
 
-## Decision
+## Considered Options
 
-A `.nvmrc` file at the repository root pins the Node version to `20.19.6`. Developers use `nvm use` to switch to this version. The Husky pre-commit hook explicitly calls `nvm use 20.19.6` before running tests to ensure the correct version is active in the hook's shell environment.
+- nvm with `.nvmrc`
+- System Node (no version management)
+- Other version managers (fnm, volta)
 
-## Consequences
+## Decision Outcome
 
-- **Positive:** Consistent Node version across all commands (dev server, build, tests, pre-commit hook).
-- **Positive:** `.nvmrc` documents the required Node version explicitly in the repository.
-- **Constraint:** Requires nvm. Developers using other version managers (fnm, volta) must align manually.
-- **Note:** The `package.json` `engines` field also declares the required Node range (`^20.19.0 || ^22.12.0`) as a secondary signal.
+Chosen option: "nvm with `.nvmrc`", because it pins the version explicitly in the repository, is already in use on the development machine, and integrates directly with the Husky pre-commit hook.
+
+A `.nvmrc` file at the repository root pins Node to `20.19.6`. The Husky pre-commit hook explicitly calls `nvm use 20.19.6` before running tests to ensure the correct version is active in the hook's shell environment.
+
+### Positive Consequences
+
+- Consistent Node version across all commands: dev server, build, tests, pre-commit hook.
+- `.nvmrc` documents the required Node version explicitly in the repository.
+
+### Negative Consequences
+
+- Requires nvm. Developers using other version managers (fnm, volta) must align manually.
+
+## Pros and Cons of the Options
+
+### nvm with `.nvmrc`
+
+- Good, because explicit version pinning visible in the repository.
+- Good, because integrates with Husky hook via `nvm use`.
+- Bad, because tied to nvm — other version managers need manual alignment.
+
+### System Node
+
+- Good, because no tooling required.
+- Bad, because version is not pinned — any system upgrade can silently break the build.
+
+### Other version managers (fnm, volta)
+
+- Good, because faster and more ergonomic than nvm for some workflows.
+- Bad, because not the currently installed tool — switching would require migration.
+
+## Links
+
+- The `package.json` `engines` field (`^18.19.1 || ^20.11.1`) provides a secondary signal for tooling that reads it.