feat(zgw): real per-request identity seam + citizen-scoping (WP-53)

Replaces the hardcoded DocumentStore.DemoOwner and the static ZgwOptions
UserId/UserRepresentation with one per-request CallerIdentity, resolved by a
pluggable IIdentityProvider (StubIdentityProvider reads X-Role/X-Subject
today; a real OIDC/DigiD provider swaps in without touching any consumer).

- Domain/Authorization/{CallerIdentity,IIdentityProvider,StubIdentityProvider}.cs
  + a resolution middleware in Program.cs, right after correlation-id.
- Authz.ResolvePrincipal(ctx) keeps its signature (now reads ctx.Caller().Role),
  so its ~15 call sites needed no changes.
- Every endpoint that passed DocumentStore.DemoOwner to a store now passes
  ctx.Caller().Bsn.
- ZgwTokenProvider gains Mint(CallerIdentity) alongside the original Mint()
  (kept for calls not tied to one citizen); ZgwHttpClient threads an optional
  caller through to pick the right overload.
- IZaakSource gains ListMyCases(caller, now) — the citizen-scoped read
  OpenZaakZaakSource backs with ZGW's rol__...__inpBsn filter. GET /applications
  now routes through it instead of ApplicationStore directly, closing the last
  "reads a static store" gap for a citizen-facing endpoint.

Backend 159/159 tests (+8, incl. an HTTP-level two-identity scoping proof),
npm run ci green, no api-client drift.

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

docs/project/backlog/README.md

@@ -103,7 +103,7 @@ for its existing violations, so every WP ends green.
 | [WP-50](WP-50-openzaak-create-zaak.md)                 | OpenZaak create-zaak (first write slice)                                           | 9 · OpenZaak/ZGW            | done   |
 | [WP-51](WP-51-openzaak-documenten.md)                  | OpenZaak Documenten (DRC) upload + zaak link                                       | 9 · OpenZaak/ZGW            | done   |
 | [WP-52](WP-52-openzaak-notificaties.md)                | OpenZaak Notificaties (NRC) live status via webhook                                | 9 · OpenZaak/ZGW            | done   |
-| [WP-53](WP-53-inbound-identity-and-citizen-scoping.md) | Inbound identity seam + citizen-scoping (per-request BSN, ZGW audit claims)        | 9 · OpenZaak/ZGW            | todo   |
+| [WP-53](WP-53-inbound-identity-and-citizen-scoping.md) | Inbound identity seam + citizen-scoping (per-request BSN, ZGW audit claims)        | 9 · OpenZaak/ZGW            | done   |
 | [WP-54](WP-54-openzaak-integration-harness.md)         | Docker OpenZaak integration-test harness (opt-in, live round-trip)                 | 9 · OpenZaak/ZGW            | todo   |
 
 Sequencing dependencies (stated in the WPs too): 01 before 10–15 (axe covers story churn);

docs/project/backlog/WP-53-inbound-identity-and-citizen-scoping.md

@@ -1,6 +1,6 @@
 # WP-53 — Inbound identity + citizen-scoping (the ZGW auth seam)
 
-Status: todo
+Status: done
 Phase: 9 — OpenZaak / ZGW integration
 
 ## Why
@@ -94,16 +94,18 @@ param `rol__betrokkeneIdentificatie__natuurlijkPersoon__inpBsn=<bsn>` on `GET {Z
 
 ## Acceptance criteria
 
-- [ ] No `DocumentStore.DemoOwner` reference remains in request handling (grep clean); ownership
+- [x] No `DocumentStore.DemoOwner` reference remains in request handling (grep clean); ownership
       comes from the resolved identity.
-- [ ] ZGW JWT carries the acting citizen's `user_id`/`user_representation` (test-verified).
-- [ ] A citizen read returns only that BSN's zaken (local + ZGW-stub tests); admin read unchanged.
-- [ ] `dotnet test` green; `npm run ci` green with **no api-client drift** (FE contract intact).
+- [x] ZGW JWT carries the acting citizen's `user_id`/`user_representation` (test-verified).
+- [x] A citizen read returns only that BSN's zaken (local + ZGW-stub tests); admin read unchanged.
+- [x] `dotnet test` green; `npm run ci` green with **no api-client drift** (FE contract intact).
 
 ## Verification
 
-`cd backend && dotnet test`; manual: `X-Role`/`X-Subject` (or `?role=`) still switches identity
-offline; with `Zgw:Enabled=true` (WP-54 harness) a citizen sees only their zaken.
+`cd backend && dotnet test` (159/159, incl. 8 new); `dotnet format --verify-no-changes` clean;
+`npm run ci` green (no api-client drift). Manual: `X-Role`/`X-Subject` still switch identity
+offline (no header → the seeded citizen, drafter); with `Zgw:Enabled=true` (WP-54 harness) a
+citizen would see only their zaken via the new `rol__…__inpBsn` filter.
 
 ## Out of scope
 
@@ -112,6 +114,27 @@ session sync (CLAUDE.md out-of-scope list).
 
 ## Risks
 
-- Missing a `DemoOwner` call site → a citizen sees another's data. Mitigate: grep gate in the
-  acceptance criteria + a test that two identities don't see each other's cases.
-- ZGW rol filter param name is exact and version-sensitive; assert it in the stub-handler test.
+- Missing a `DemoOwner` call site → a citizen sees another's data. Mitigated: grep gate (clean)
+  + `ApplicationTests.Applications_are_scoped_to_the_caller_bsn` (two `X-Subject` identities,
+  HTTP end-to-end) proving neither sees the other's cases.
+- ZGW rol filter param name is exact and version-sensitive; asserted in
+  `OpenZaakZaakSourceTests.ListMyCases_filters_by_the_callers_bsn`.
+
+## Session notes
+
+Built as designed — no premise in the Decisions/Context block turned out stale. One
+implementation choice not spelled out in the WP: `Authz.ResolvePrincipal(HttpContext ctx)` kept
+its exact signature (now `new(ctx.Caller().Role)` instead of re-reading `X-Role` itself), so
+none of its ~15 call sites needed touching — "flow it to Authz.ResolvePrincipal" didn't require
+threading `CallerIdentity` through every endpoint that resolves a `Principal`. `ZgwTokenProvider`
+grew a `Mint(CallerIdentity)` overload alongside the existing parameterless `Mint()` (kept for
+calls not tied to one citizen — the admin cross-owner `ListCases`, and Catalogi metadata lookups)
+rather than replacing it outright, so `ZgwOptions.UserId`/`UserRepresentation` stay meaningful as
+the BFF's own system identity. `IZaakSource`/`IDocumentSource` gained an explicit `CallerIdentity`
+parameter on every citizen-scoped method (`ListMyCases`, `CreateZaak`, `Upload`, `LinkToZaak`)
+rather than resolving it ambiently via `IHttpContextAccessor` — kept it unit-testable without any
+DI/HttpContext ceremony (see `StubIdentityProviderTests`, the `ZgwTokenProviderTests` addition).
+`GET /applications` (the citizen's own dashboard list) is now routed through
+`IZaakSource.ListMyCases` instead of calling `ApplicationStore` directly — closing the exact gap
+`openzaak-integration.md`'s ACL caveat used to flag for that endpoint; under `Zgw:Enabled=true` it
+would now source from OpenZaak (BSN-filtered) like `/admin/cases` already did.

docs/reference/openzaak-integration.md

@@ -55,7 +55,7 @@ precisely what was just computed; under OpenZaak, three calls happen in order:
    (`statustypen?zaaktype=...`, lowest `volgnummer`); marks the zaak as freshly opened.
 3. **POST rol** (`{ZrcBaseUrl}/rollen`) — `roltype` resolved via a Catalogi GET
    (`roltypen?zaaktype=...&omschrijvingGeneriek=initiator`); `betrokkeneIdentificatie.inpBsn`
-   set to the aanvraag's owner (BSN) — the current stand-in for real identity (WP-53).
+   set to the aanvraag's owner (BSN) — the acting citizen resolved by the identity seam (WP-53).
 
 The created zaak's `identificatie` becomes the returned `Referentie`; its status maps to the
 same coarse `InBehandeling` shape `ZgwZaakMapper` already uses for a freshly-opened zaak
@@ -140,6 +140,39 @@ pointing at this BFF's public URL:
 }
 ```
 
+## Identity — the acting citizen (WP-53)
+
+Everything above used to hardcode a single owner (`DocumentStore.DemoOwner`) and a single static
+ZGW audit identity (`ZgwOptions.UserId`/`UserRepresentation`). WP-53 replaced both with one
+per-request `CallerIdentity` (subject BSN + display name + role, `Domain/Authorization/
+CallerIdentity.cs`):
+
+- **Resolution**: an `IIdentityProvider` runs once per request (middleware in `Program.cs`,
+  right after the correlation-id middleware) into `HttpContext.Items`, read back everywhere via
+  `ctx.Caller()`. `StubIdentityProvider` (the only implementation today, **not a security
+  boundary**) reads the existing `X-Role` header (unchanged — mirrors the FE's `?role=` toggle)
+  plus a new `X-Subject` header for the BSN, defaulting to the single seeded citizen — so every
+  request that doesn't send `X-Subject` (which is every request today; the FE never sends it)
+  behaves exactly as before this WP. A production provider swaps in real OIDC/DigiD claims
+  without touching a single consumer.
+- **`Authz.ResolvePrincipal(ctx)` kept its exact signature** — it now reads `ctx.Caller().Role`
+  instead of the header directly, so its ~15 call sites across `Program.cs` needed no changes.
+- **Ownership**: every endpoint that used to pass `DocumentStore.DemoOwner` to a store
+  (`ApplicationStore`, `DocumentStore`, `BriefStore`) now passes `ctx.Caller().Bsn`.
+- **The ZGW JWT** (`ZgwTokenProvider`) grew a `Mint(CallerIdentity)` overload alongside the
+  original parameterless `Mint()`: citizen-scoped calls (create-zaak, upload, zaak-link, the
+  citizen's own case list) mint with the caller's BSN/name as `user_id`/`user_representation`;
+  calls not tied to one citizen (the admin cross-owner list, Catalogi metadata lookups) keep
+  minting with the BFF's own system identity from `ZgwOptions`. `ZgwHttpClient.GetAsync`/
+  `PostAsync` take an optional `CallerIdentity?` that picks which `Mint` overload runs.
+- **Citizen-scoped reads**: `IZaakSource` gained `ListMyCases(CallerIdentity, now)` alongside the
+  existing admin-only `ListCases(now)`. `LocalZaakSource` filters `ApplicationStore.List(bsn)`
+  (unchanged local behaviour); `OpenZaakZaakSource` appends ZGW's
+  `rol__betrokkeneIdentificatie__natuurlijkPersoon__inpBsn=<bsn>` query filter to `GET
+  {ZrcBaseUrl}/zaken`. `GET /applications` (the citizen's own dashboard) now routes through this
+  instead of calling `ApplicationStore` directly — the last "reads a static store directly" gap
+  the ACL caveat below used to flag for a citizen-facing endpoint.
+
 ## The five ZGW APIs (context for later slices)
 
 | API          | Component | Used by                                             |
@@ -233,19 +266,19 @@ Principles this demonstrates:
   comment in `ZgwZaakMapper` show where the ACL is deliberately thin — an ACL need not be
   complete on day one, but its shortcuts should be visible.
 
-Caveat: `IZaakSource` covers the cases **read + create** path (WP-49/50), `IDocumentSource`
-covers **upload + zaak-link** (WP-51), and the inbound `POST /zgw/notificaties` webhook
-(WP-52) closes the read/write/document/notify arc. Other BFF endpoints still read
-`SeedData`/static stores directly — ACL-ready (the DTO seam exists) but not yet swappable.
-What's left in this arc is the two cross-cutting WPs production needs: **WP-53** (a real
-per-request identity seam + citizen-scoping — today the owner/BSN is stubbed) and **WP-54** (a
-docker OpenZaak harness + opt-in integration test — today everything is fixture/mock-tested
-against no live instance).
+Caveat: `IZaakSource` covers the cases **read (admin + citizen-scoped) + create** path
+(WP-49/50/53), `IDocumentSource` covers **upload + zaak-link** (WP-51), the inbound
+`POST /zgw/notificaties` webhook (WP-52) closes the read/write/document/notify arc, and WP-53
+threaded a real per-request `CallerIdentity` through all of it (ownership + the ZGW audit
+claims). Other BFF endpoints (reference data like `SeedData`'s BRP/DUO mimics) still read static
+stores directly — ACL-ready (the DTO seam exists) but not yet swappable, and not part of this
+arc. What's left is **WP-54**: a docker OpenZaak harness + opt-in integration test — today
+everything is fixture/mock-tested against no live instance.
 
 ## See also
 
 - [ADR-0005 — OpenZaak behind the BFF](architecture/0005-openzaak-behind-bff.md) — the decision.
 - [ADR-0001 — BFF-lite + decision DTOs](architecture/0001-bff-lite-decision-dtos.md) — why the FE doesn't change.
-- [WP-49](../project/backlog/WP-49-openzaak-zaken-read-seam.md) (this), WP-50/51 (CRUD arc so far), WP-52 (notificaties), WP-53/54 (identity seam + integration harness).
+- [WP-49](../project/backlog/WP-49-openzaak-zaken-read-seam.md) (this), WP-50/51 (CRUD arc so far), WP-52 (notificaties), WP-53 (identity seam + citizen-scoping), WP-54 (integration harness, open).
 - `backend/src/BigRegister.Api/Zgw/` — the client; `Data/IZaakSource.cs`/`Data/IDocumentSource.cs` — the seams.
 - [ZGW standard (VNG)](https://vng-realisatie.github.io/gemma-zaken/) · [OpenZaak auth docs](https://open-zaak.readthedocs.io/en/stable/client-development/authentication.html).