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/0004-http-interceptors-pipeline.md

@@ -1,29 +1,46 @@
-# ADR 0004: HTTP Interceptors Pipeline
+# Handle API base URL, auth token, and errors via HTTP interceptors
 
-**Date:** 2026-04-26
-**Status:** Accepted
+- Status: accepted
+- Date: 2026-04-26
 
-## Context
+## Context and Problem Statement
 
-Every API call requires the same three cross-cutting concerns:
+Every API call requires three cross-cutting concerns: prepending the API base URL, attaching the JWT bearer token, and unwrapping error responses into a consistent shape. How should these be applied across all HTTP calls without duplicating logic in each service?
 
-1. Prepend the API base URL so services don't hard-code it.
-2. Attach the JWT bearer token when one exists.
-3. Unwrap error responses into a consistent shape.
+## Considered Options
 
-Handling these ad hoc in each service would duplicate logic and couple services to environment details.
+- Three chained HTTP interceptors
+- Per-service base URL and token handling
+- Single utility wrapper function
 
-## Decision
+## Decision Outcome
 
-Three functional interceptors are chained in order in `app.config.ts`:
+Chosen option: "Three chained HTTP interceptors", because they centralise cross-cutting concerns transparently and require no changes to individual services.
 
-1. **`apiInterceptor`** — prepends `environment.apiBaseUrl` to every outgoing request URL. Consequence: all services call relative paths (e.g. `/skydive/jumps`), never absolute URLs.
-2. **`tokenInterceptor`** — attaches `Authorization: Token <jwt>` when a token exists in `JwtService`.
-3. **`errorInterceptor`** — unwraps `err.error` from HttpErrorResponse and rethrows, so subscribers receive the API error payload directly.
+### Positive Consequences
 
-## Consequences
+- Services use relative paths (e.g. `/skydive/jumps`) — environment-agnostic.
+- Auth header injection is transparent to all services.
+- Uniform error payload shape across the entire application.
 
-- **Positive:** Services are environment-agnostic. Swapping the API base URL requires changing only `environment.ts`.
-- **Positive:** Auth header injection is transparent to all services.
-- **Positive:** Error handling is uniform across the application.
-- **Constraint:** Services must always use relative paths starting with `/`. Absolute URLs would get the base URL prepended, breaking them.
+### Negative Consequences
+
+- Services must always use relative paths starting with `/`. Passing an absolute URL would cause the base URL to be prepended twice.
+
+## Pros and Cons of the Options
+
+### Three chained HTTP interceptors
+
+- Good, because zero duplication — logic defined once, applied everywhere.
+- Good, because services remain unaware of environment or auth details.
+- Bad, because interceptors apply globally — opting out requires explicit handling.
+
+### Per-service base URL and token handling
+
+- Good, because each service controls its own behaviour explicitly.
+- Bad, because duplicates the same logic across every service.
+
+### Single utility wrapper function
+
+- Good, because more explicit than interceptors.
+- Bad, because all service calls must go through the wrapper — easy to bypass accidentally.