docs: archive the finished backlogs (RD-30)

Two backlog trees are complete: `docs/project/backlog/` (75 files, every
WP done) and `docs/project/refactor-backlog-setup/` (the arc before it).
Move both under `docs/project/archive/` with `git mv`, so history stays
intact through `git log --follow`. `SHOWCASE-ROADMAP.md` moves with them,
because it points at the now-archived backlog README.

Add `docs/project/archive/README.md`. It states that these trees are
historical and names the two directories that are still live.

Repoint every inbound reference named in RD-30's Files table: CLAUDE.md,
the root README, both backend READMEs, `LetterHtml.cs`, `a11y.mdx`, the
`document-feature` and `new-ssp` skills, and the readable-codebase PLAN,
README, and RD-19 ticket. Fix two upward-relative links inside the moved
WP files (WP-68, WP-69) that gained a directory level and would otherwise
break. Repoint `.prettierignore`'s two agent-prompt exclusions to their
new path, so prettier keeps leaving those files' exact wording alone.

Mark RD-30 done and check off its acceptance criteria; flip its README
row to done.

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

docs/project/archive/backlog/WP-61-behandelportal-bootstrap.md

@@ -0,0 +1,83 @@
+# WP-61 — Bootstrap the behandelportal app
+
+Status: done (behandelportal@6b0c6ce — separate sibling repo, not a commit in this one)
+Phase: 11 — Behandelportal
+
+## Why
+
+ADR-0002 already designed the Behandelaar/backoffice as a separate sibling frontend app,
+not a folder in this repo. Nothing exists yet — `/beheer/zaken` is confirmed to be only a
+cross-owner list+delete, no treatment workflow. The `new-ssp` skill exists precisely to
+bootstrap a new portal from this template; this slice is running that recipe for real,
+with no business context yet — an empty, correctly-scaffolded shell.
+
+## Read first
+
+- `.claude/skills/new-ssp/SKILL.md`
+- [ADR-0002 — user groups & bounded contexts](../reference/architecture/0002-user-groups-and-bounded-contexts.md)
+- [ADR-0001 — BFF-lite decision DTOs](../reference/architecture/0001-bff-lite-decision-dtos.md)
+
+## Decisions (pre-made, don't relitigate)
+
+- Follow `new-ssp`'s own "keep vs. strip" checklist as-is: keep the `shared/ui` kernel,
+  tooling/CI gates, ADRs 0001-0003; strip the four citizen contexts and citizen branding.
+- The new app talks to the same `BigRegister.Api` backend — no new backend service
+  (confirmed by ADR-0002: contexts integrate through the backend).
+- Repo layout: **separate sibling repo** at `/home/eho/repos/behandelportal` (fresh clone —
+  `scripts/create-frontend.mjs`'s own header comment says to run it inside a fresh clone, not
+  against this repo's working tree).
+
+## Resolution (kickoff deviation from the vanilla recipe)
+
+`create-frontend.mjs` unconditionally renames the backend project regardless of
+`--skip-backend` (that flag only gates the `gen:api` regen step) — which conflicts with
+"no new backend service" above. Resolved by running the script as-is
+(`--name Behandelportal --context behandeling --skip-backend`), then in the new repo:
+deleting `backend/` entirely, vendoring its `swagger.json` into `api-contract/swagger.json`,
+and pointing `gen:api` at `nswag run nswag.json` against that vendored doc instead of
+regenerating from a live backend. Dev workflow is two terminals: `BigRegister.Api` runs from
+_this_ repo on `:5000`, Behandelportal serves on `:4201` via its own unchanged
+`proxy.conf.json`.
+
+Also found and fixed by hand (real bugs in `create-frontend.mjs`, not specific to this WP):
+`plop context`'s `.dependency-cruiser.js` insertion anchors on the `showcase`
+`CONTEXT_ALLOWED` entry, which is already stripped by the time `plop context` runs in the
+same invocation — so a freshly scaffolded context silently gets **no boundary-fence
+entry**, and `dep:check` passes green with the architecture guarantee simply absent. Not
+re-fixed in `create-frontend.mjs` itself this pass (out of scope here) — just compensated for by
+hand in the new repo.
+
+## Files
+
+Whatever `new-ssp`'s recipe touches (new app root, `package.json`, shared/ui copy or
+workspace reference, CI config) — enumerate at kickoff by following the skill.
+
+## Steps
+
+1. Run the `new-ssp` bootstrap per its own checklist.
+2. Confirm the known un-genericizable rough edges it flags (`shared/ui/debug-state/`, the
+   `/dashboard` route) are handled per the skill's own guidance (delete / TODO stopgap)
+   rather than re-solved from scratch.
+3. Land an empty landing/login page only — no `behandeling` context yet (that's WP-64+).
+4. Get the new app's own CI green.
+
+## Acceptance criteria
+
+- [x] New app boots and its own `npm run ci` is green.
+- [x] No citizen-facing business context (`registratie`, `herregistratie`, `brief`,
+      `showcase`) present.
+- [x] Points at the same backend (`BigRegister.Api`) as this repo, no new backend stood
+      up.
+
+## Verification
+
+`npm run ci` in the new app; manual smoke — app loads to an empty shell page.
+
+## Out of scope
+
+Any `behandeling` screens (WP-64/65), identity (WP-62), status lifecycle (WP-63).
+
+## Risks
+
+`new-ssp`'s own docs already name its rough edges (`debug-state`, `/dashboard`) — budget
+time for those rather than being surprised by them.