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>

backend/openzaak/README.md

@@ -55,6 +55,31 @@ and is **excluded** from the default `dotnet test` run and from CI (`ci.yml`,
 `scripts/ci-local.sh` both filter `Category!=Integration`) — it only passes with this harness
 up, so it never runs where the harness doesn't exist.
 
+## Notifications-enabled profile (WP-58)
+
+The base harness above never delivers a real notification (`NOTIFICATIONS_DISABLED: 'true'`,
+no celery worker) — fine for the read/write ZGW seam, not for proving a live webhook round-trip.
+An opt-in overlay adds the one celery worker needed, flips that flag, and points OpenZaak
+straight at this repo's own BFF webhook (no real Notificaties API/NRC in this harness — see
+[docs/reference/openzaak-integration.md](../../docs/reference/openzaak-integration.md)'s
+"Notifications-enabled profile" section for why and how). Needs the repo root's own
+`docker compose up` (or an equivalent `api` container) running too, since the celery worker
+reaches the BFF by container name on that network:
+
+```bash
+docker compose run --rm -d --name atomic-design-poc-api-1 --service-ports \
+  -e Zgw__NotificatieAuthorization='<a secret>' api      # repo root
+
+cd backend/openzaak
+docker compose -f docker-compose.openzaak.yml -f docker-compose.openzaak.notificaties.yml up -d
+./bootstrap-catalogus.sh
+BFF_AUTH='<the same secret>' ./bootstrap-notificaties.sh
+BFF_AUTH='<the same secret>' ./verify-notificatie.sh   # proves a real delivery, end to end
+```
+
+To go back to the fast, no-notifications default: `docker compose -f docker-compose.openzaak.yml
+up -d --remove-orphans` (drops the celery worker, restores `NOTIFICATIONS_DISABLED: 'true'`).
+
 ## Tear down
 
 ```bash
@@ -100,9 +125,9 @@ app change.
 - `docker-compose.openzaak.yml` — postgres (postgis), redis, a one-shot `web-init` (runs
   Django migrations then `setup_configuration` against `setup_configuration/data.yaml`), and
   `web` (the OpenZaak API on `:8000`). Pinned to `openzaak/open-zaak:1.29.1`. No
-  celery/celery-beat/celery-flower/nginx — trimmed for a lean, fast-booting harness; add them
-  back only if a later WP needs a real async notification delivery round-trip here (WP-52's
-  webhook is already covered by fixture tests against no live instance).
+  celery/celery-beat/celery-flower/nginx — trimmed for a lean, fast-booting harness; layer
+  `docker-compose.openzaak.notificaties.yml` (WP-58) on top for a real async notification
+  delivery round-trip.
   `NOTIFICATIONS_DISABLED=true` is required, not optional: without it, OpenZaak 500s (and
   **rolls back the whole create**) on any notified resource — see the compose file's comment.
 - `setup_configuration/data.yaml` — the declarative, scripted alternative to clicking through
@@ -125,8 +150,22 @@ app change.
   harness's `appsettings.json`, so `OpenZaakDocumentSource` isn't reachable here yet; add the
   grant (scoped to a real `informatieobjecttype`, which this script would also need to seed)
   when a later WP wires DRC content into this harness.
-- **Not here**: Documenten (DRC) / Notificaties (NRC) content — add if a later WP needs to prove
-  those round-trips against a live instance too (WP-51/52 are fixture-tested today).
+- **Not here**: Documenten (DRC) content, or a real Notificaties API (NRC) — add DRC content if a
+  later WP needs to prove that round-trip against a live instance too (WP-51 is fixture-tested
+  today). A real NRC is a separate application (`open-notificaties`) this harness deliberately
+  doesn't stand up — WP-58's notifications-enabled profile (below) proves live delivery without
+  one, since this harness only ever has one subscriber.
+- `docker-compose.openzaak.notificaties.yml` (WP-58) — opt-in overlay: one celery worker for
+  OpenZaak (async notification delivery needs it) + `NOTIFICATIONS_DISABLED: 'false'`, joined to
+  the repo root's own compose network so it can reach the `api` container by name (tried
+  `host.docker.internal:host-gateway` first; this environment's rootless Podman doesn't route
+  container→host-port traffic through it). See "Notifications-enabled profile" below.
+- `bootstrap-notificaties.sh` (WP-58) — points OpenZaak's `NotificationsConfig` at the BFF's
+  webhook via a `zgw_consumers.Service` (`update_or_create`, idempotent) instead of provisioning
+  a real NRC `abonnement`; preflights that the BFF is reachable with the right secret first
+  (a misconfigured target here means every write to a notified resource 500s and rolls back).
+- `verify-notificatie.sh` (WP-58) — the runnable end-to-end check: PATCHes the seeded zaak, polls
+  the BFF's own `/admin/audit` (WP-41) for the resulting `zgw:notificatie`/`allow` row.
 - `docker-compose.openzaak.prod.yml` (WP-55) — production overrides layered on top of
   `docker-compose.openzaak.yml`: real `SECRET_KEY`/DB password/site domain/allowed-hosts from
   required env vars (fails fast if unset), password DB auth instead of `trust`, `IS_HTTPS: 'yes'`.