feat(gateway): wire GATEWAY_HONEYTOKEN through the deploy

The planted honeytoken bearer trap already existed in the gateway + compose, but
no workflow fed GATEWAY_HONEYTOKEN, so it was always empty (inert). Wire the
per-contour TEST_/PROD_GATEWAY_HONEYTOKEN secret into the ci deploy, prod-deploy
and prod-rollback env (the prod path via the shared deploy/write-prod-env.sh),
document it (deploy/README + .env.example), and fix the stale compose comment.

Empty secret = trap off (no ":?" guard), so a deploy is safe before the operator
sets the value + plants the bait. On prod (IP ban on) presenting it earns a 24h
ban + alarm; on test (ban off) it logs + a ban metric.

GF_SMTP_ENABLED is enabled separately via the TEST_/PROD_GF_SMTP_ENABLED Gitea
variables (=true) — no code change.

deploy/docker-compose.yml

@@ -231,8 +231,8 @@ services:
       # in prod — the test contour arrives as one shared NAT address, so a ban there
       # would be self-inflicted (the honeypot still logs). The prod deploy forces it on
       # in env.sh (deploy/write-prod-env.sh), not via a Gitea variable. GATEWAY_HONEYTOKEN
-      # is the planted bearer trap; it is currently unset on every contour (no Gitea entry
-      # feeds it), so the trap is inert until an operator wires a secret.
+      # is the planted bearer trap, fed from the per-contour TEST_/PROD_GATEWAY_HONEYTOKEN
+      # secret; empty (unset secret) leaves the trap off.
       GATEWAY_ABUSE_BAN_ENABLED: ${GATEWAY_ABUSE_BAN_ENABLED:-false}
       GATEWAY_HONEYTOKEN: ${GATEWAY_HONEYTOKEN:-}
       GATEWAY_LOG_LEVEL: ${LOG_LEVEL:-info}