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/docker-compose.openzaak.notificaties.yml

@@ -1,9 +1,9 @@
-# WP-58 — notifications-enabled overlay, layered ON TOP of docker-compose.openzaak.yml
+# Notifications-enabled overlay, layered ON TOP of docker-compose.openzaak.yml
 # (never alone):
 #
 #   docker compose -f docker-compose.openzaak.yml -f docker-compose.openzaak.notificaties.yml up -d
 #
-# The base file stays the WP-54 fast-iteration default (NOTIFICATIONS_DISABLED=true, no
+# The base file stays the fast-iteration default (NOTIFICATIONS_DISABLED=true, no
 # worker) so nobody testing the read/write seam has to pull/boot this. This overlay flips
 # NOTIFICATIONS_DISABLED off and adds the one celery worker needed to actually deliver a
 # notification (see base file's ponytail note).
@@ -14,7 +14,7 @@
 # bootstrap-notificaties.sh points OpenZaak's NotificationsConfig straight at the BFF's webhook
 # instead — same delivery proof (a real write → a real HTTP POST → the BFF's audit trail), far
 # less harness to stand up and keep alive. Add a real NRC (+ abonnement/kanaal routing) if a
-# later WP needs more than one subscriber or real kanaal-filtered fan-out.
+# later change needs more than one subscriber or real kanaal-filtered fan-out.
 #
 # No celery-beat here: send_notification is a plain async task (client.post on save), not a
 # scheduled one — beat only matters on a real NRC's polling side, which this harness doesn't have.