docs(backlog): fix stale WP-19 CI description; add per-step model guidance

WP-19: the Files section still described the originally-planned CI approach
(background servers with & + wait-on); the actual implementation (documented in
ci.yml's own comment and playwright.config.ts) moved server lifecycle into
Playwright's webServer to fix the 2-hour e2e hang. Recorded as a Deviation entry
and corrected the Files section to match reality. Spot-checked the rest of the WP
(retryClicked wiring, the currentScenario() claim, the still-open retry gaps in
registration-detail/aanvraag-detail/brief) against current code — all still hold.

Session protocol: replace the removed model mandate with per-step guidance —
Opus for planning, Sonnet for implementation, Haiku subagents for simple
read-only CLI checks — so cost matches the step's difficulty, not the whole WP.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/project/backlog/README.md

@@ -11,6 +11,12 @@ This backlog **supersedes `docs/project/SHOWCASE-ROADMAP.md`**.
 
 - **One WP per session.** Read `CLAUDE.md`, this README, the WP file, and the WP's
   "Read first" list — then execute. Do not start the next WP in the same session.
+- **Match the model to the step, not the whole session.** Plan/design under Opus (`/model
+opus`) — a WP's approach and edge cases deserve the stronger model. Switch to Sonnet to
+  write the code once the plan is approved — routine implementation against a pre-made
+  Decisions block doesn't need Opus. Delegate simple, read-only CLI checks (running a test
+  suite, `grep`/`git status`, verifying a file exists) to a Haiku subagent where the harness
+  supports it — proportion cost to the step's difficulty, not the WP's.
 - The **Decisions** block in each WP is pre-made — don't relitigate it.
 - A WP ends **GREEN** (below) with its acceptance criteria checked off and its Status
   updated to `done` (+ commit hash).

docs/project/backlog/WP-19-e2e-smoke.md

@@ -46,10 +46,11 @@ wired together — the thing a demo/reference app should be able to prove first.
 - New `e2e/error-state.spec.ts` — the `?scenario=error` path.
 - `package.json` — add `"e2e": "playwright test"` script; `@playwright/test` devDependency.
 - `.github/workflows/ci.yml` — new job `e2e`, steps: checkout, setup-node, setup-dotnet,
-  `npm ci`, `npx playwright install --with-deps chromium`, start backend
+  `npm ci`, `npx playwright install --with-deps chromium`, `npm run e2e`.
-  (`dotnet run --project backend/src/BigRegister.Api &`), `npm start &` (or `ng
+  `timeout-minutes: 15` per the hardened workflow convention already in `ci.yml`. Playwright's
-serve` backgrounded), wait-on both ports, `npm run e2e`. `timeout-minutes: 15`
+  own `webServer` config (`playwright.config.ts`) starts + waits-for-ready + tears down both
-  per the hardened workflow convention already in `ci.yml`.
+  the backend and `ng serve` inside that one step — see the "backgrounding servers" deviation
+  below for why this replaced the originally-planned `&`/`wait-on` approach.
 
 ## Steps
 
@@ -80,6 +81,14 @@ serve` backgrounded), wait-on both ports, `npm run e2e`. `timeout-minutes: 15`
 
 ## Deviation from the original plan
 
+- **Backgrounding servers as separate CI steps doesn't work.** The Files section originally
+  planned starting the backend and `ng serve` with `&` in one step, then `wait-on`-ing both
+  ports in a later step. A process backgrounded with `&` in one GitHub/Gitea Actions `run:`
+  step is killed when that step's shell exits — so the later `wait-on` step hung forever on
+  servers that were already gone (**the 2-hour e2e hang**). Fixed by moving server lifecycle
+  into Playwright itself: `playwright.config.ts`'s `webServer` array starts both processes,
+  waits for each to be ready, runs the suite, and tears them down — all inside the single
+  `npm run e2e` process/step, so it's self-contained locally and in CI alike.
 - **Found and fixed a real bug while writing the error-path spec**: `AsyncComponent`'s
   built-in `retry()` only calls `.reload()` on a `[resource]` input — every real page
   (`dashboard`, `registration-detail`, `aanvraag-detail`, `brief`) feeds `<app-async>`