feat(behandelportal): WP-62 medewerker caller identity + authz seam

Splits backend CallerIdentity into the two ADR-0002 §3 actor kinds
(ZorgverlenerCaller/MedewerkerCaller), a stub X-Medewerker/X-Rollen header
path mirroring WP-53's citizen stub, and Authz.CanBeoordelen as the first
medewerker capability — backend-only, no consumer until WP-64. Also fixes
the backlog README's stale WP-61 status (done, but table said todo).

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

docs/reference/roles-and-access.md

@@ -32,6 +32,18 @@ Both are wired only under `isDevMode()` — they do not exist in a production bu
 Mechanism: `src/app/shared/infrastructure/role.ts` reads the role and the HTTP interceptor stamps it
 as an `X-Role` header on role-aware requests; the backend resolves it into a `Principal`.
 
+## 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
+**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.
+
 ## What each role unlocks
 
 Capabilities are resolved server-side (`backend/src/BigRegister.Api/Domain/Authorization/Authz.cs`,