feat(behandelportal): WP-64 werkvoorraad (queue) screen

New GET /werkvoorraad endpoint lists aanvragen still open (Ingediend/InBehandeling),
gated by the medewerker capability (CanBeoordelen) rather than the admin role — reuses
the existing ApplicationSummaryDto, no new DTO. GET /me now surfaces aanvraag:beoordelen
for a behandelaar so the FE can gate with the same AccessStore/capabilityGuard idiom
every other page uses.

FE: a behandeling domain type deliberately narrower than ssp's full AanvraagStatus
union (only the two open tags — illegal states unrepresentable), composed into a
werkvoorraad-list organism from existing shared/ui molecules. Replaces WP-61's
scaffold placeholder as the app's real landing page.

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

docs/project/backlog/WP-64-behandelportal-werkvoorraad.md

@@ -1,6 +1,6 @@
 # WP-64 — Behandelportal: werkvoorraad (queue) screen
 
-Status: todo
+Status: done
 Phase: 11 — Behandelportal
 
 ## Why
@@ -44,10 +44,36 @@ behandelportal app (domain/infrastructure/application/ui per the house layering)
 
 ## Acceptance criteria
 
-- [ ] Werkvoorraad screen lists aanvragen needing treatment for an authenticated
+- [x] Werkvoorraad screen lists aanvragen needing treatment for an authenticated
       medewerker.
-- [ ] `npm run ci` green in the behandelportal app; Storybook story present.
-- [ ] Endpoint follows BFF-lite discipline (decision-enriched, not raw passthrough).
+- [x] `npm run ci` green in the behandelportal app; Storybook story present.
+- [x] Endpoint follows BFF-lite discipline (decision-enriched, not raw passthrough).
+
+## Outcome
+
+`GET /werkvoorraad` reuses the existing `ApplicationSummaryDto`/`IZaakSource.ListCases` —
+no new DTO — filtered server-side to `Status.Tag is "Ingediend" or "InBehandeling"`. Gated
+by a new `Werkvoorraad` local-function twin of `CasesAdmin`, but checking
+`Authz.CanBeoordelen(ctx.Caller())` (the CallerIdentity directly) rather than a
+role-only `Principal` — a zorgverlener with `X-Role=admin` is still denied (covered by a test).
+
+One course correction beyond the pre-made decisions: `GET /me` didn't expose any
+capability a medewerker could hold (`RoleCapabilities` only switches on `PrincipalRole`,
+which every `MedewerkerCaller` also carries but doesn't determine `CanBeoordelen`). Added
+one line — `if (Authz.CanBeoordelen(ctx.Caller())) caps.Add("aanvraag:beoordelen")` — and a
+matching `Capability` union member in `libs/shared`, so the FE page can use the same
+deny-by-default `AccessStore`/`capabilityGuard` idiom every other gated page uses (avoids a
+wasted 403 GET and a denial flash), instead of inventing a second gating mechanism.
+
+FE: the queue item's domain type (`behandeling/domain/werkvoorraad-item.ts`) is
+deliberately **narrower** than the SSP's full `AanvraagStatus` union — only
+`Ingediend`/`InBehandeling` — so a case the backend's filter let through with any other
+tag is a parse error, not a silently-rendered row. Composed entirely from existing
+`libs/shared/ui` molecules (`ApplicationListComponent` + `ApplicationLinkComponent`, the
+same ones ssp's dashboard uses) via one new organism, `WerkvoorraadListComponent` — no new
+atom. The stopgap `behandeling.page.ts`/`BehandelingPage` (WP-61's scaffold placeholder,
+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.
 
 ## Verification