feat(openzaak): bounded retry + flagged write divergence (WP-60)

Local aanvraag/document writes and their paired ZGW writes aren't
transactional; a ZGW failure after the local write succeeds used to
diverge silently. ZgwHttpClient now retries transport-shaped failures
(not 500, which can follow a partial commit on the non-idempotent
statussen/rollen POSTs), and a ZGW failure that survives retry sets
Aanvraag.ZgwError plus a zgw:divergence audit row instead of failing
or diverging quietly. No outbox/reconcile job: three request-triggered
write paths don't justify a persisted queue that would also need to
carry citizen PII for the JWT audit claims.

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

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

@@ -62,8 +62,11 @@ Any further behandelportal screens beyond beoordeling.
 
 ## Risks
 
-If Phase 10's WP-60 (write-divergence resilience) hasn't landed yet, this introduces a
-second unprotected write pair — call this out explicitly if the two phases aren't
-sequenced together in practice.
+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.
 
-Depends on: WP-65. Benefits from (but doesn't strictly require) WP-60.
+Depends on: WP-65.