refactor: strip WP-/RB- ticket refs from backend (RD-19)

The backend half of the sweep RD-18 did for the front end. git blame
holds the provenance and stays correct when the code moves; the
comment names a closed ticket and tells the reader nothing the
sentence around it does not.

public/letter.css and LetterHtml.golden.html change together, because
the renderer inlines the CSS and the golden file snapshots the
result.

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

backend/openzaak/README.md

@@ -1,4 +1,4 @@
-# OpenZaak integration harness (WP-54)
+# OpenZaak integration harness
 
 A real OpenZaak, for developing/testing the ZGW seam (`backend/src/BigRegister.Api/Zgw/`)
 against something that isn't a fixture or a stub `HttpMessageHandler`. Deliberately **not**
@@ -22,7 +22,7 @@ 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.
 
-**Idempotent (WP-56)** — every resource is looked up by its natural key (the same field(s)
+**Idempotent** — 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
@@ -81,7 +81,7 @@ 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)
+## Notifications-enabled profile
 
 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.
@@ -137,7 +137,7 @@ already high going in; `ZGW_DEBUG_HTTP=1` on `api`, see `docker-compose.openzaak
 diagnostics to help nail the cause next time it reproduces). Prints the URLs to check
 afterward and the teardown commands.
 
-Two caveats, both non-fatal (WP-60 catches and flags rather than surfacing an error):
+Two caveats, both non-fatal (the BFF catches and flags rather than surfacing an error):
 **only `herregistratie` has a seeded zaaktype** here, so submit that wizard to prove a real
 write; and **no Documenten content is seeded**, so a document upload's ZGW half no-ops (pick
 "per post" in the wizard's document step, or ignore it).
@@ -148,7 +148,7 @@ write; and **no Documenten content is seeded**, so a document upload's ZGW half
 docker compose -f docker-compose.openzaak.yml down -v
 ```
 
-## Production (WP-55)
+## Production
 
 This dev harness stays dev-only: hardcoded `SECRET_KEY`, `POSTGRES_HOST_AUTH_METHOD=trust`,
 `IS_HTTPS: 'no'`, a client secret checked into `setup_configuration/data.yaml`. A real
@@ -188,7 +188,7 @@ app change.
   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; layer
-  `docker-compose.openzaak.notificaties.yml` (WP-58) on top for a real async notification
+  `docker-compose.openzaak.notificaties.yml` 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.
@@ -197,14 +197,14 @@ app change.
   one `bigregister-test` client with `heeft_alle_autorisaties: false` — this YAML mechanism
   (`vng_api_common`'s `ApplicatieConfigurationModel`) has no field for granular scopes at all,
   so the client starts with zero Autorisaties; `bootstrap-catalogus.sh` grants the exact ones
-  it needs (WP-57).
+  it needs.
 - `bootstrap-catalogus.sh` — the business content (catalogus/zaaktype/zaak/…) `setup_configuration`
   has no YAML for; every field value here was checked against OpenZaak's own OpenAPI spec and a
   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). Idempotent (WP-56) — see "Bring it up" above.
-  Also grants `bigregister-test`'s Autorisaties via `manage.py shell` (WP-57, see the script's
+  `procesType` on the public VNG selectielijst API). Idempotent — see "Bring it up" above.
+  Also grants `bigregister-test`'s Autorisaties via `manage.py shell` (see the script's
   top comment): `ztc` scopes (`catalogi.lezen`/`catalogi.schrijven`, this script's own
   content-creation needs) up front, `zrc` scopes (`zaken.aanmaken`/`zaken.bijwerken`/
   `zaken.lezen`, scoped to the one zaaktype the BFF and this script both use) once that
@@ -213,26 +213,26 @@ app change.
   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) 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
+  later change needs to prove that round-trip against a live instance too (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
+  doesn't stand up — the 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
+- `docker-compose.openzaak.notificaties.yml` — 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
+- `bootstrap-notificaties.sh` — 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
+- `verify-notificatie.sh` — the runnable end-to-end check: PATCHes the seeded zaak, polls
+  the BFF's own `/admin/audit` for the resulting `zgw:notificatie`/`allow` row.
+- `docker-compose.openzaak.prod.yml` — 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'`.
   Adds no image/service of its own — see "Production" above for the full flow.
-- `setup_configuration/data.prod.yaml.template` (WP-55) — the prod counterpart of `data.yaml`
+- `setup_configuration/data.prod.yaml.template` — the prod counterpart of `data.yaml`
   with no secret in it (`${OPENZAAK_CLIENT_SECRET}` etc. as placeholders); `render-prod-secrets.sh`
   fills it in to the gitignored `data.prod.yaml`, which the prod compose override mounts over
   the container's `data.yaml`.