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/bootstrap-notificaties.sh

@@ -0,0 +1,59 @@
+#!/usr/bin/env bash
+# WP-58 — points OpenZaak's own NotificationsConfig straight at this repo's BFF webhook
+# (POST /api/v1/zgw/notificaties, WP-52) instead of standing up a real Notificaties API (NRC)
+# + abonnement — see docker-compose.openzaak.notificaties.yml's ponytail note for why. Requires
+# that overlay running (adds the celery worker + flips NOTIFICATIONS_DISABLED) AND the repo
+# root's own `docker compose up` running (the overlay joins its `api` container's network —
+# tried host.docker.internal first, but this harness's celery worker couldn't reach a
+# host-bound port through it; see the overlay's comment) with
+# Zgw__NotificatieAuthorization=$BFF_AUTH set on that `api` service.
+#
+# Idempotent: `update_or_create` on the Service's fixed slug, same shape as bootstrap-catalogus.sh.
+set -euo pipefail
+cd "$(dirname "${BASH_SOURCE[0]}")"
+
+COMPOSE_FILES=(-f docker-compose.openzaak.yml -f docker-compose.openzaak.notificaties.yml)
+# Container-to-container (the celery worker reaching the root project's `api` container by
+# name, see the overlay file) — this script itself runs on the HOST though, so its own
+# preflight check below hits the BFF at $BFF_LOCAL_ROOT (localhost, the published port) instead.
+BFF_API_ROOT="${BFF_API_ROOT:-http://api:5000/api/v1/zgw/}"
+BFF_LOCAL_ROOT="${BFF_LOCAL_ROOT:-http://localhost:5000/api/v1/zgw/}"
+BFF_AUTH="${BFF_AUTH:-wp-58-local-harness-not-for-prod}"
+
+echo "Preflight: is the BFF reachable at $BFF_LOCAL_ROOT with the shared secret configured?"
+status=$(curl -sS -o /dev/null -w '%{http_code}' -X POST \
+  -H "Authorization: $BFF_AUTH" -H 'Content-Type: application/json' \
+  -d '{"kanaal":"preflight","hoofdObject":"http://example.com/preflight","resource":"status","resourceUrl":"http://example.com/preflight","actie":"create","aanmaakdatum":"2026-01-01T00:00:00Z","kenmerken":{}}' \
+  "${BFF_LOCAL_ROOT}notificaties")
+if [ "$status" != "204" ]; then
+  echo "FAILED: expected 204 from the BFF's webhook, got $status. From the repo root:" >&2
+  echo "  docker compose run --rm -d --name atomic-design-poc-api-1 --service-ports \\" >&2
+  echo "    -e Zgw__NotificatieAuthorization='$BFF_AUTH' api" >&2
+  exit 1
+fi
+echo "  ok (204)"
+
+docker compose "${COMPOSE_FILES[@]}" exec -T --workdir /app/src web python manage.py shell <<PY
+from notifications_api_common.models import NotificationsConfig
+from zgw_consumers.constants import APITypes, AuthTypes
+from zgw_consumers.models import Service
+
+service, _ = Service.objects.update_or_create(
+    slug="bff-webhook",
+    defaults=dict(
+        label="BIG-register BFF webhook (WP-58)",
+        api_type=APITypes.orc,
+        api_root="$BFF_API_ROOT",
+        auth_type=AuthTypes.api_key,
+        header_key="Authorization",
+        header_value="$BFF_AUTH",
+    ),
+)
+config = NotificationsConfig.get_solo()
+config.notifications_api_service = service
+config.save()
+print(f"NotificationsConfig.notifications_api_service -> {service.api_root}")
+PY
+
+echo
+echo "Notifications configured. Run ./verify-notificatie.sh to prove a live delivery."