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/project/backlog/WP-62-medewerker-identity-authz.md

@@ -1,6 +1,6 @@
 # WP-62 — Backend: medewerker caller identity + authz seam
 
-Status: todo
+Status: done
 Phase: 11 — Behandelportal
 
 ## Why
@@ -50,17 +50,17 @@ SSO — out of scope per CLAUDE.md, same as DigiD).
 
 ## Acceptance criteria
 
-- [ ] `CallerIdentity` represents both actor kinds without breaking any existing
+- [x] `CallerIdentity` represents both actor kinds without breaking any existing
       zorgverlener call site (WP-53's tests still green).
-- [ ] A stub medewerker identity resolves from a request header, mirroring the existing
+- [x] A stub medewerker identity resolves from a request header, mirroring the existing
       citizen stub.
-- [ ] At least one capability flag (`canBeoordelen`) computable for a medewerker
+- [x] At least one capability flag (`canBeoordelen`) computable for a medewerker
       identity, unit-tested.
 
 ## Verification
 
 `cd backend && dotnet test` (existing WP-53 tests unaffected + new medewerker tests
-green).
+green) — 182/182 (168 baseline + 14 new). `dotnet format --verify-no-changes` clean.
 
 ## Out of scope
 
@@ -71,3 +71,26 @@ Any actual backoffice endpoint using this (WP-64+); real employee SSO/eHerkennin
 If the union is modeled as a bolt-on rather than replacing the flat type, existing
 zorgverlener call sites could break — mitigated by keeping WP-53's existing tests as a
 regression gate.
+
+## Outcome notes
+
+- **The `Files` list undersold the blast radius.** `CallerIdentity` became `abstract`
+  with two derived records (`ZorgverlenerCaller`, `MedewerkerCaller`), which is a hard
+  compile error at every `new CallerIdentity(...)` and every `.Bsn` read outside
+  `Domain/Authorization/` — 17 `ctx.Caller().Bsn` reads in `Program.cs` alone, plus 6
+  seam signatures (`IDocumentSource.Upload`, `IZaakSource.ListMyCases` and their
+  Local/OpenZaak implementations) narrowed to `ZorgverlenerCaller` where `.Bsn` is used
+  as an ownership key, plus test fixtures in 4 test files.
+  `CallerIdentity.SubjectId` (BSN or medewerkerId) is the trick that kept the
+  token-mint-only call sites (`ZgwTokenProvider.Mint`, `ZgwHttpClient`, `IZaakSource
+.CreateZaak`, `IDocumentSource.LinkToZaak`) compiling with zero signature changes —
+  they never needed the BSN specifically, just _an_ id for the ZGW audit trail.
+- **`Role` (`PrincipalRole`, the existing dev-role stand-in) stays on the base record**,
+  not per-variant — it's an orthogonal axis (both actor kinds can be any dev role),
+  which is why `Authz.ResolvePrincipal(ctx) => new(ctx.Caller().Role)` and its ~15
+  call sites needed no changes at all.
+- **A new extension, `ctx.Zorgverlener()`**, narrows `CallerIdentity` to
+  `ZorgverlenerCaller` or throws — deliberately a 500, not a 403, since no medewerker
+  reaches any SSP endpoint today (nothing sends `X-Medewerker` yet). WP-64 should
+  map this to a 403 once real backoffice traffic exists; flagging it now so it isn't
+  mistaken for an oversight.