feat(behandelportal): WP-65a beoordeling detail (read) + fix unreachable medewerker login

New GET /beoordeling/{id} shows one aanvraag's status, linked documents, and a
canBesluiten decision flag, gated by the same CanBeoordelen capability as the
werkvoorraad list. Reads through IZaakSource.ListCases rather than a new seam
method (WP-66 needs one anyway for the real write); owner BSN is masked.

Fixes a real gap found while wiring this up: the behandelportal's login was still
WP-61's copied citizen/BSN DigiD flow, so nothing ever sent X-Medewerker and the
werkvoorraad screen (WP-64) always denied in a real browser. A dev-only
medewerkerInterceptor (mirrors the existing ?role= stand-in as ?rollen=) fixes that.

WP-65's own Risks note authorized splitting read from write across sessions given
its size; this is the read half. The decision-recording mutation is next (65b).

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

docs/reference/roles-and-access.md

@@ -35,14 +35,21 @@ as an `X-Role` header on role-aware requests; the backend resolves it into a `Pr
 ## Actor kinds (backend, WP-62)
 
 `X-Role`/`Principal` above is a coarse role that applies to **either** of two actor kinds the
-backend now models (ADR-0002 §3): a **zorgverlener** (this SSP's citizen — has a BSN) or a
+backend now models (ADR-0002 §3): a **zorgverlener** (the SSP's citizen — has a BSN) or a
 **medewerker** (backoffice employee — no BSN, has `Rollen`). `StubIdentityProvider` picks the
 medewerker kind from a dev header, `X-Medewerker` (+ `X-Rollen`), mirroring `X-Role`/`X-Subject`
-above — **the SSP's FE never sends either header**; they exist only for the backend's own tests
-and for the behandelportal (WP-64+) to use later. `Authz.CanBeoordelen(caller)` is the first
-medewerker capability — a rol-based decision flag (`MedewerkerRol.Behandelaar`), not a role
-entry on `/me`, since `/me`'s `RoleCapabilities` is keyed on `Principal` and can't see the actor
-kind.
+above. The SSP's FE never sends either header — it has no medewerker screens. The
+**behandelportal** does: `apps/behandelportal/src/app/auth/infrastructure/medewerker.interceptor.ts`
+stamps every request as one fixed stand-in medewerker (dev-only, same `isDevMode()` gate as
+`roleInterceptor`), since this app has no real employee-SSO login yet (ADR-0002 §3 — the two
+apps' login flows are expected to diverge, and this stand-in is that flow's placeholder).
+`?rollen=` (sticky per tab, mirroring `?role=`) picks the medewerker's rollen —
+`?rollen=geen` exercises the deny path; the default is `behandelaar`.
+`Authz.CanBeoordelen(caller)` is the first medewerker capability — a rol-based decision flag
+(`MedewerkerRol.Behandelaar`), surfaced on `GET /me` as `aanvraag:beoordelen` (appended
+alongside `RoleCapabilities`'s role-derived set, since that switch is keyed on `Principal` and
+can't see the actor kind) — gates the behandelportal's `/dashboard` werkvoorraad queue (WP-64)
+and its `/aanvraag/:id` beoordeling detail (WP-65).
 
 ## What each role unlocks