feat(openzaak): idempotent catalogus/zaaktype/zaak provisioning (WP-56)

bootstrap-catalogus.sh now looks up every resource by its natural key before
creating it (catalogus by domein+rsin, zaaktype by catalogus+identificatie,
statustype by zaaktype+volgnummer, roltype by zaaktype+omschrijvingGeneriek,
zaaktype-publish by checking `concept` first, zaak by identificatie,
status/rol by existence-under-the-zaak), so rerunning against an
already-seeded instance reuses what's there instead of erroring.

The WP's original plan (move this into OpenZaak's `setup_configuration`
mechanism) turned out not to be achievable: reading the actual
django_setup_configuration steps installed inside the open-zaak image shows
no step exists for Catalogi/Zaken content anywhere in this OpenZaak version
— only sites/credentials/applicaties/selectielijst. Documented as a
deviation; the WP's own Risks section already anticipated this and sanctioned
falling back to an idempotent script.

Verified live: fresh instance -> full run (all created) -> integration test
green -> reran the script twice more against the same instance (all reused,
identical URLs, no duplicates) -> integration test still green.

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

backend/openzaak/README.md

@@ -22,13 +22,24 @@ published), and one zaak (`BIG-2026-000123`) with an initiator rol for the seede
 (`111222333` — the same fixture BSN `OpenZaakZaakSourceTests.cs` uses). It writes what it
 seeded to `seeded.env` (gitignored) and prints a summary.
 
-**Not idempotent** — re-running against the same (already-seeded) instance fails on OpenZaak's
-`domein`+`rsin` uniqueness constraint for the catalogus. Reset with:
+**Idempotent (WP-56)** — every resource is looked up by its natural key (the same field(s)
+OpenZaak enforces identity on: catalogus by `domein`+`rsin`, zaaktype by `catalogus`+
+`identificatie`, statustype by `zaaktype`+`volgnummer`, roltype by `zaaktype`+
+`omschrijvingGeneriek`, zaak by `identificatie`) before creating it, so re-running against an
+already-seeded instance reuses what's there instead of erroring. Safe to run repeatedly
+against a long-lived instance, not just once per fresh volume — a full reset is still
+available if you want a truly clean slate:
 
 ```bash
 docker compose -f docker-compose.openzaak.yml down -v && docker compose -f docker-compose.openzaak.yml up -d
 ```
 
+This content has no `setup_configuration` (declarative-YAML) equivalent: reading the
+`django_setup_configuration` steps installed inside the `openzaak/open-zaak:1.29.1` image
+itself confirms the only app-registered steps are sites/credentials/applicaties (already used
+by `setup_configuration/data.yaml`) and Selectielijst API config — nothing for Catalogi/Zaken
+content. Hence this stays a script, made safe to rerun instead.
+
 ## Run the integration test against it
 
 ```bash
@@ -103,7 +114,7 @@ app change.
   live run of this exact script, not guessed (two OpenZaak quirks it works around: a zaaktype
   needs ≥1 resultaattype and 2 statustypen before it can be published, and its
   `selectielijstklasse` and the zaaktype's `selectielijstProcestype` must reference the same
-  `procesType` on the public VNG selectielijst API).
+  `procesType` on the public VNG selectielijst API). Idempotent (WP-56) — see "Bring it up" above.
 - **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).
 - `docker-compose.openzaak.prod.yml` (WP-55) — production overrides layered on top of