v1.0.34 — Transaction IDs in WAF block responses

Resolves public issue #29.

Coraza block responses now display the audit transaction ID in a plain-text
browser response and the X-WAF-Transaction-ID response header. Administrators
can match this ID to transaction.id in audit logs or transaction_id in
stored WAF events to identify the rules involved. Rule details and request
contents are not exposed to clients.

The change covers request and response inspection (phases 1–4) and body-limit
rejections. HEAD requests receive the header without a body. Denial status
codes are preserved and block responses are marked Cache-Control: no-store.
Allowed traffic, DetectionOnly mode, engine-off traffic, and upstream errors
retain their existing behavior. Blocks outside Coraza (such as geo/IP ACLs,
authentication, or rate limits) do not have a Coraza transaction ID.

The image retains Caddy 2.11.4, coraza-caddy 2.6.2, and Coraza 3.8.1. A small
connector patch covers both request errors and response interruptions; Caddy
error routes alone cannot cover all of those paths.

Upgrade

Set WAF_IMAGE_TAG=1.0.34, pull the images, and recreate the services. Preserve
any TCP/UDP port overrides. Once Caddy is ready, restart the admin API so it
restores the saved configuration. No database migration or new site setting
is required. The migration head remains 0037_merge_forwarding_reputation.

Validation

The Caddy image build runs 11 regression cases against real Coraza transactions:
phases 1–4, request/response size limits, HEAD, DetectionOnly, engine off, allowed
requests, and upstream 403 responses. Block IDs are checked against the actual
JSON audit log and a spoofed client ID is rejected by the default configuration.

Rollback

Restore WAF_IMAGE_TAG=1.0.33, recreate the services, and restart the API after
Caddy is ready. No schema downgrade is needed. Block responses will no longer
display the transaction ID.