feat(acl): resolve the zaaktype by identificatie, not a pinned URL (S-27, closes #113) (#118)

## What & why

The ACL was handed a **pinned zaaktype URL** (`Acl__Defaults__ZaaktypeUrl`) + informatieobjecttype URL. OpenZaak assigns those UUIDs at creation, so every stack had to seed the catalogus and then capture + inject the resulting URLs out of band (CI's `run-domain-check.sh`; the local `local-seed`→`acl.env` bootstrap from ADR-0020). Brittle, and a stale/placeholder URL failed opaquely (OpenZaak 400).

Now **the ACL resolves them itself** from OpenZaak's Catalogi API by stable business key:
- config `ZaaktypeIdentificatie` (`BIG-REGISTRATIE`) / `InformatieobjecttypeOmschrijving` (`Diploma`);
- a `CachedZaaktypeCatalog` resolves **lazily on first use** and caches (success only, so a pre-publish miss is retried — no startup ordering coupling);
- a clear "No published … found" error replaces the opaque placeholder 400.

Design in **ADR-0021** (proposed in #117).

Closes #113
Closes #117

## Consequences (the payoff)

No stack captures/injects a server-assigned URL any more — `docker-compose.yml`/`.local.yml`, `run-domain-check.sh` and `local-seed` all drop it; the local `acl.env` shrinks to a single line.

**One thing S-27 can't remove** (confirmed empirically during this work): OpenZaak validates the `zaaktype` field on zaak-create with Django's URLValidator and **rejects a single-label host** (`http://openzaak:8000/…` → `zaaktype: bad-url`). So the ACL's **base URL** must still point at a URL-valid host (a container IP); that base-URL injection from ADR-0020 stays (local `acl.env` now carries only it; CI keeps `ACL_OPENZAAK_BASEURL`). ADR-0021 records this.

## Definition of Done

- [x] Linked issues (#113 slice, #117 adr-proposal).
- [x] TDD — resolver + gateway-lookup unit tests, updated `AclService` tests (50 unit tests green).
- [x] Implementation makes them pass; refactor of both compose stacks + verify scripts follows.
- [x] Conventional Commits referencing #113.
- [ ] CI green — see below.
- [x] `docker compose up` reaches green health — verified: fresh `make local` + `make verify-local` green with **no zaaktype-URL injection**; `acl.env` is base-URL-only.
- [x] Docs — ADR-0021 + demo-script S-27 note.
- [x] ADR added (ADR-0021).
- [x] Demo note appended.

## Verification done locally

- **50 unit tests** pass (resolver resolve/cache/retry-on-failure; gateway match/miss/blank-key; all `AclService` paths).
- **6 ACL integration tests** pass against a live seeded OpenZaak — incl. resolving the zaaktype + Diploma iot by business key, and a clear error for an unknown identificatie.
- **Fresh `make local` + `make verify-local`**: full flow (submit → werkbak → openbaar) green; `acl.env` = `Acl__OpenZaak__BaseUrl` only.
- `make lint` clean; ACL mutation ratchet run locally (see checks).

## Notes for reviewers

- `IZaakGateway` gains two resolve methods; `AclService` depends on the new `IZaaktypeCatalog` (singleton, so the cache persists).
- Supersedes the pinned-URL mechanism; ADR-0021 documents that ADR-0020's `seed-env`/entrypoint shim are **simplified** (base-URL only), not deleted, because of the URLValidator constraint above.

Reviewed-on: #118

docs/demo-script.md

@@ -26,9 +26,31 @@ make verify-local     # → "OK — a fresh local stack completed the flow with
 #    test123); it shows as INGESCHREVEN in the openbaar register at http://localhost:8141.
 ```
 
-> The zaaktype UUID is server-assigned, so `local-seed` writes the real URL into a shared volume as
-> `acl.env` and the ACL sources it on startup (ADR-0020). The cleaner long-term fix — the ACL
-> resolving its zaaktype by `identificatie` — is tracked separately as S-27 (#113).
+> The zaaktype is discovered by the ACL itself since S-27 (below); `local-seed`'s `acl.env` now
+> carries only OpenZaak's IP base URL, which the ACL still needs because OpenZaak rejects a
+> single-label host on zaak-create (ADR-0020 + ADR-0021).
+
+---
+
+## S-27 — ACL resolves its zaaktype by identificatie, not a pinned URL (#113, ADR-0021)
+
+**Outcome:** the ACL discovers its BIG zaaktype (by `identificatie`) and diploma informatieobjecttype
+(by `omschrijving`) from OpenZaak's Catalogi API, instead of being handed the server-assigned URLs.
+No user-visible behaviour change — the flow runs exactly as before — but no stack captures/injects a
+zaaktype URL any more, and a missing catalogus now fails with a clear message instead of an opaque 400.
+
+```bash
+# The live ACL↔OpenZaak integration test proves resolution against a real seeded OpenZaak:
+make verify-acl     # → "resolves the published BIG-REGISTRATIE zaaktype + Diploma informatieobjecttype by business key"
+
+# End-to-end unchanged (the ACL self-discovers the zaaktype during the flow):
+make verify-local   # local stack — still green, now with no zaaktype-URL injection
+make verify-domain  # CI stack — recreates the ACL pointed only at OpenZaak's IP (no URL to inject)
+```
+
+> The ACL still needs its OpenZaak base URL at a URL-valid host (a container IP): OpenZaak's
+> URLValidator rejects a single-label host like `openzaak:8000` on zaak-create. So ADR-0020's base-URL
+> injection stays; only the zaaktype/informatieobjecttype **URL** injection is gone (ADR-0021).
 
 ---