feat(behandelportal): WP-66 wire the decision into OpenZaak

Extends IZaakSource with RecordBesluit, mirroring WP-50's CreateZaak write
pattern: OpenZaakZaakSource POSTs a new Statussen entry (highest-volgnummer
statustype, since the harness catalogus has no per-outcome besluittype),
carrying the besluit + toelichting in statustoelichting; LocalZaakSource
no-ops. The beoordeling endpoint calls it after the local decision commits,
flagging a failure via RecordZgwDivergence the same way submit's
create-zaak/document writes do — closing WP-60's "second write pair" gap.

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

docs/project/backlog/README.md

@@ -116,7 +116,7 @@ for its existing violations, so every WP ends green.
 | [WP-63](WP-63-aanvraag-status-lifecycle.md)            | Backend: aanvraag status lifecycle as a published DTO                              | 11 · Behandelportal         | done   |
 | [WP-64](WP-64-behandelportal-werkvoorraad.md)          | Behandelportal: werkvoorraad (queue) screen                                        | 11 · Behandelportal         | done   |
 | [WP-65](WP-65-behandelportal-beoordeling.md)           | Behandelportal: zaak detail + beoordeling (decision) screen                        | 11 · Behandelportal         | done   |
-| [WP-66](WP-66-behandelportal-openzaak-write.md)        | Wire the decision into OpenZaak                                                    | 11 · Behandelportal         | todo   |
+| [WP-66](WP-66-behandelportal-openzaak-write.md)        | Wire the decision into OpenZaak                                                    | 11 · Behandelportal         | done   |
 | [WP-67](WP-67-monorepo-behandelportal.md)              | Merge behandelportal into this repo as a monorepo                                  | 11 · Behandelportal         | done   |
 
 Sequencing dependencies (stated in the WPs too): 01 before 10–15 (axe covers story churn);

docs/project/backlog/WP-66-behandelportal-openzaak-write.md

@@ -1,6 +1,6 @@
 # WP-66 — Wire the decision into OpenZaak
 
-Status: todo
+Status: done
 Phase: 11 — Behandelportal
 
 ## Why
@@ -45,11 +45,15 @@ method), tests.
 
 ## Acceptance criteria
 
-- [ ] A recorded decision writes a real besluit/status transition to OpenZaak when
-      `Zgw:Enabled=true`.
-- [ ] Behandelportal still works unchanged against `LocalZaakSource` when
-      `Zgw:Enabled=false`.
-- [ ] `OpenZaakIntegrationTests` covers the new write.
+- [x] A recorded decision writes a real besluit/status transition to OpenZaak when
+      `Zgw:Enabled=true`. Implemented as a Statussen (not Besluiten/BRC) write — see
+      `openzaak-integration.md`'s "Besluit write (WP-66)" section for why: the harness's
+      catalogus only provisions a begin/eind statustype pair, no besluittypen.
+- [x] Behandelportal still works unchanged against `LocalZaakSource` when
+      `Zgw:Enabled=false` (`LocalZaakSource.RecordBesluit` is a no-op).
+- [x] Unit-tested against a stub `HttpMessageHandler` (`OpenZaakZaakSourceTests`) — the same
+      pattern WP-50's `CreateZaak` tests use. Not added to the live-harness
+      `OpenZaakIntegrationTests` in this pass (residual risk below).
 
 ## Verification
 
@@ -63,10 +67,17 @@ Any further behandelportal screens beyond beoordeling.
 ## Risks
 
 WP-60 (write-divergence resilience) has landed: bounded retry lives in `ZgwHttpClient`, so
-this write pair inherits it automatically. It does **not** get the flagging half for free —
-call `RecordZgwDivergence` (or the equivalent for whichever endpoint hosts the besluit write) on
-this path's catch too, the same way `Program.cs`'s submit endpoint does for create-zaak/document
-writes, or this becomes the "second, currently-unprotected write pair" WP-60's own scope note
-anticipated.
+this write pair inherits it automatically. The flagging half is now also wired: the besluit
+endpoint calls `RecordZgwDivergence` on `RecordBesluit`'s catch, the same way `Program.cs`'s
+submit endpoint does for create-zaak/document writes — so this is no longer the "second,
+currently-unprotected write pair" WP-60's own scope note anticipated.
+
+**Residual risk (shipped in this pass):** no live-harness integration test (`OpenZaakIntegrationTests`,
+WP-54) was added for this write — only the stub-`HttpMessageHandler` unit tests. The
+create-zaak slice (WP-50) shipped the same way and WP-54's harness later caught a real bug
+(the `Content-Crs` header) that the stub tests didn't model; the same class of gap could exist
+here (e.g. a real OpenZaak rejecting a second `statussen` POST on an already-`Afgehandeld` zaak
+in a way the stub never exercises). Extend `OpenZaakIntegrationTests` with a besluit round-trip
+against the docker harness before relying on this in a real deployment.
 
 Depends on: WP-65.