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-58-openzaak-notifications.md

@@ -1,6 +1,6 @@
 # WP-58 — Real notifications (celery + scripted abonnement)
 
-Status: todo
+Status: done
 Phase: 10 — OpenZaak production hardening
 
 ## Why
@@ -44,25 +44,85 @@ today that registration step is manual.
 
 ## Acceptance criteria
 
-- [ ] A notifications-enabled harness profile runs celery/celery-beat and delivers a real
+- [x] A notifications-enabled harness profile runs a celery worker and delivers a real
       notification end-to-end to the BFF's webhook.
-- [ ] The `abonnement` registration step is a script, re-runnable without erroring on an
-      already-registered subscription.
+- [x] Provisioning is a script, re-runnable without erroring on an already-configured target.
+
+## What actually happened
+
+The Decisions block assumed OpenZaak itself could be pointed at, celery-wired, and made to
+deliver to a subscribed `abonnement` — checking the running image (`grep -ril abonnement` inside
+the `web` container) found nothing: **OpenZaak does not serve the Notificaties API.** It's a
+separate application (`openzaak/open-notificaties`, its own image/DB/celery/beat stack).
+Standing one up for real `abonnement`/kanaal-filtered routing would mean ~5 new services (a
+second Postgres, web, worker, beat, plus the NRC↔AC authorization chain) for a benefit this
+harness doesn't need — there is exactly one subscriber (this repo's own BFF), never N. Re-scoped
+before writing any code (confirmed with the user): OpenZaak's own `NotificationsConfig` points
+straight at the BFF's webhook via a `zgw_consumers.Service` (`auth_type=api_key`) instead — no
+NRC, no `abonnement`, same delivery proof (a real write → OpenZaak's celery worker → a real HTTP
+POST → the BFF's audit trail). The two "no `abonnement`" acceptance-criteria words above were
+edited out for the same reason.
+
+- `docker-compose.openzaak.notificaties.yml` — an opt-in overlay (not `profiles:`, matching
+  WP-55's prod-override precedent) adding one celery worker (not celery-beat: `send_notification`
+  is a plain async task fired on save, not a scheduled one — beat only matters on a real NRC's
+  polling side) and flipping `NOTIFICATIONS_DISABLED` off. The two changes are inseparable:
+  `NOTIFICATIONS_GUARANTEE_DELIVERY` defaults true, so the moment that flag is false, every write
+  to a notified resource 500s-and-rolls-back unless `NotificationsConfig` already has a client —
+  hence `bootstrap-notificaties.sh` configuring it is not a separate step.
+- Reaching the BFF from the worker turned out to be the real obstacle, not the Django/celery
+  wiring. `extra_hosts: host.docker.internal:host-gateway` (the plan's first choice) resolves
+  fine but every TCP connect through it timed out — confirmed live: this environment's rootless
+  Podman doesn't route container→host-port traffic that way. Fix: join the overlay's `celery`
+  service to the repo root's own `docker compose up` network (`external: true`, by the
+  `atomic-design-poc_default` name compose derives from the repo directory) and reach the BFF by
+  its container name (`api`) instead — container-to-container, which this exact stack already
+  proved reliable (`celery` already talks to `db`/`redis` that way). One more trap on that path:
+  `docker compose run --name api ...` does **not** register the `api` DNS alias other containers
+  need (only `docker compose up -d api` does) — cost a debugging round-trip before switching to
+  `up -d` (via a temporary, uncommitted `docker-compose.override.yml`) for the live verification.
+- `bootstrap-notificaties.sh` — `update_or_create` on the `Service`'s fixed slug (idempotent);
+  preflights the BFF's webhook with a synthetic notification body first (204 required) so a
+  misconfigured target fails before touching OpenZaak, not after (a later write would otherwise
+  500-and-rollback with no obvious cause).
+- `verify-notificatie.sh` — the runnable end-to-end check. First attempt triggered the write via
+  a second `statussen` POST (the "final" status) — 403'd: WP-57's narrowed `zaken.aanmaken` scope
+  permits exactly **one** status per zaak ("Met de 'zaken.aanmaken' scope mag je slechts 1 status
+  zetten"). Switched the trigger to a zaak `PATCH` (`toelichting`), covered by the already-granted
+  `zaken.bijwerken` and trivially repeatable. Second attempt used the _final_ statustype anyway
+  for a different reason and got a 400 ("Zaak has no resultaat") — OpenZaak requires a `resultaat`
+  before the closing status; the `PATCH` sidesteps that precondition entirely too.
+- Verified for real, twice: `bootstrap-catalogus.sh` (idempotent re-run, all "exists") →
+  `bootstrap-notificaties.sh` (preflight 204, `Service` configured) → `verify-notificatie.sh`
+  (PATCH → polled `/admin/audit` → found the delivered `zgw:notificatie`/`allow` row) → reran
+  both WP-58 scripts again under the same running harness (still idempotent, delivered again).
+  Also confirmed the negative case directly: `POST /zgw/notificaties` with no `Authorization`
+  header, and with a wrong one, both 401 — the shared-secret gate isn't just accepting anything.
+  Backend suite stayed green throughout (159/159, `dotnet test --filter Category!=Integration`).
+  Test infrastructure (the temporary `docker-compose.override.yml`, the manually-created `api`
+  container) was torn down / reconciled back to the pre-session baseline afterward.
 
 ## Verification
 
-Bring up the notifications-enabled profile; create a zaak/status change; confirm the BFF's
-`/zgw/notificaties` endpoint receives and logs it.
+Bring up the notifications-enabled profile (`backend/openzaak/README.md`'s "Notifications-enabled
+profile" section); run `./bootstrap-catalogus.sh && ./bootstrap-notificaties.sh &&
+./verify-notificatie.sh`. The last script fails loudly (with celery/worker log diagnostics) if no
+delivered notification shows up in the BFF's `/admin/audit` within 60s.
 
 ## Out of scope
 
 Cache invalidation on notification receipt (flagged separately in
 `openzaak-integration.md` as a `ponytail:` marker, not part of this slice);
-celery-flower/monitoring UI.
+celery-flower/monitoring UI. A real Notificaties API (NRC) + `abonnement`/kanaal-filtered
+routing (see "What actually happened") — add one if a later WP needs more than this harness's
+single subscriber.
 
 ## Risks
 
-Celery/celery-beat add real operational surface (another process to keep alive) — scope
-this WP to "works, documented," not a fully monitored deployment.
+Celery adds real operational surface (another process to keep alive) — scope this WP to
+"works, documented," not a fully monitored deployment. The direct-to-BFF shortcut means this
+harness doesn't exercise real `abonnement`/kanaal-filter validation — a production deployment's
+NRC-based path (documented in `openzaak-integration.md`) is untested by this harness by
+construction.
 
 Depends on: WP-56 (provisioning mechanism this extends).