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/reference/openzaak-integration.md

@@ -96,7 +96,9 @@ BSN for the JWT's audit claims — PII in a new table) — see WP-60 for the ful
   `/beheer/audit`) — see `RecordZgwDivergence`. The endpoint still returns 200 with the local
   reference/status: that's truthful (the reference _is_ what would become the zaak's
   `identificatie`) and never branches on `Zgw:Enabled` (an offline `LocalZaakSource` never
-  throws, so the catch is dead code there).
+  throws, so the catch is dead code there). The besluit endpoint (WP-66, see below) wraps
+  `IZaakSource.RecordBesluit` in the same try/catch → `RecordZgwDivergence` shape — the second
+  write pair this section's "Repair" bullet used to anticipate.
 - **The document upload path flags differently.** `OpenZaakDocumentSource.Upload` catches its
   own ZGW failure (config gap or transport) and logs it, but doesn't set a separate flag column
   — `DocumentStore.Get(id).DrcUrl == null` is already the meaningful "not registered in ZGW yet"
@@ -104,8 +106,8 @@ BSN for the JWT's audit claims — PII in a new table) — see WP-60 for the ful
 - **Repair.** No automated reconcile job exists yet — a flagged zaak is repairable on demand
   because its (would-be) `identificatie` always equals the aanvraag's `Referentie`, so a future
   admin action can `GET /zaken?identificatie=...` and either adopt the existing zaak or retry
-  `CreateZaak`. Deferred until a second write pair (WP-66) or a real deployment makes it worth
-  building — at which point the outbox question above is also worth re-asking.
+  `CreateZaak`/`RecordBesluit`. WP-66 landed as the second write pair without needing an outbox —
+  a real deployment is still the trigger to re-ask that question, not slice count on its own.
 
 ## Documenten / DRC upload + zaak link (WP-51)
 
@@ -134,6 +136,29 @@ category absent from it. Unlike the zaak side, an upload's ZGW failure (past
 `DocumentStore.Add`) is caught and logged rather than persisted as a separate flag column —
 see "Write resilience" below for why the two write paths differ.
 
+## Besluit write (WP-66)
+
+`POST /beoordeling/{id}/besluit` (the behandelportal's decision endpoint, WP-65b) routes its
+ZGW side-effect through `IZaakSource.RecordBesluit` the same way submit routes through
+`CreateZaak`: the local write (`ApplicationStore.RecordBesluit`) always happens first and stays
+the record of truth, then `OpenZaakZaakSource` additionally POSTs a new `statussen` entry to the
+aanvraag's zaak (`Aanvraag.ZaakUrl`, set by `CreateZaak`).
+
+There is no Besluiten (BRC) call here — the harness's catalogus (WP-56) provisions only a
+begin/eind `statustype` pair per zaaktype (`Ontvangen`/`Afgehandeld`), not one per decision
+outcome, so a real Besluiten API integration would need its own `besluittype` provisioning
+first (still "later" in the table above). Instead this reuses the exact statustype-resolution
+pattern `CreateZaak` already has (`FirstStatustypeUrlAsync`), just picking the highest
+`volgnummer` (`LastStatustypeUrlAsync`) instead of the lowest, and carries the besluit
+(`Goedkeuren`/`Afwijzen`/`MeerInfoOpvragen`) plus the behandelaar's toelichting in the status's
+free-text `statustoelichting` field so the outcome is still visible on the ZGW side.
+
+`RecordBesluit` is a no-op if the aanvraag never got a zaak (`Zgw:Enabled` was off at submit
+time, or the create diverged) — same "nothing to do" skip `LinkToZaak` uses for a null
+`zaakUrl`. `LocalZaakSource.RecordBesluit` is a no-op outright — the local decision already IS
+the record of truth there. `caller` is the acting `MedewerkerCaller` (WP-62), so the minted ZGW
+JWT's audit claims reflect the behandelaar, not a static identity.
+
 ## The ZGW client (`backend/src/BigRegister.Api/Zgw/`)
 
 - `ZgwOptions.cs` — bound from the `Zgw` appsettings section: `Enabled`, per-service base URLs