feat(openzaak): real notification delivery to the BFF webhook (WP-58)

OpenZaak doesn't serve the Notificaties API itself (it's a separate app,
open-notificaties) — standing one up for a real abonnement would triple
this harness for a benefit it doesn't need (exactly one subscriber, this
repo's own BFF). Instead, an opt-in compose overlay adds a celery worker
and points OpenZaak's NotificationsConfig straight at the BFF's webhook
via a zgw_consumers Service; bootstrap-notificaties.sh configures it
idempotently and verify-notificatie.sh proves a real write delivers to
the BFF's audit trail end-to-end.

Verified live: preflight proves the webhook's shared-secret gate both
ways (204/401), a zaak PATCH triggers real celery delivery, and rerunning
both scripts against an already-configured harness stays idempotent.

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

docs/project/backlog/WP-57-openzaak-least-privilege-scopes.md

@@ -63,7 +63,7 @@ JWT/REST layer involved, so no circularity. Two grants, both idempotent (delete-
   Only `catalogi.schrijven` is provisioning-only; the BFF itself only ever reads Catalogi.
 - `zrc`: `zaken.aanmaken` + `zaken.bijwerken` + `zaken.lezen`, scoped to the one zaaktype
   (`zaaktype=<ZT-HERREG url>`, `max_vertrouwelijkheidaanduiding=openbaar` — both fields are
-  *required* by OpenZaak's `AutorisatieValidator` for any `zaken.*` scope) — granted once
+  _required_ by OpenZaak's `AutorisatieValidator` for any `zaken.*` scope) — granted once
   `zaaktype_url` is known, right after the zaaktype is created/resolved.
 
 Reading the actual `RolViewSet`/`StatusViewSet`/`ZaakInformatieObjectViewSet`