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/project/backlog/WP-64-behandelportal-werkvoorraad.md

@@ -75,6 +75,13 @@ atom. The stopgap `behandeling.page.ts`/`BehandelingPage` (WP-61's scaffold plac
 its own TODO said to replace it) is gone; `/dashboard` now loads `WerkvoorraadPage`
 directly, and the redundant `/behandeling` route (same placeholder, two paths) was dropped.
 
+**Correction (found during WP-65):** this WP's Verification line ("manual: log in as a stub
+medewerker, see the queue populated") could not actually have passed — the behandelportal's
+login was still WP-61's copy-pasted citizen/BSN DigiD flow, nothing sent `X-Medewerker`, so
+`WerkvoorraadPage` always rendered its denial alert in a real browser. CI stayed green
+regardless (none of this WP's tests exercise the browser gate). Fixed in WP-65 with a
+dev-only `medewerkerInterceptor` — see that WP's Progress notes.
+
 ## Verification
 
 `npm run ci` in the behandelportal app; `cd backend && dotnet test`; manual: log in as a