fix(deploy): honeypot tag dropped — Caddy applies header_up delete after set

The @honeypot block both deleted and set X-Scrabble-Honeypot in one reverse_proxy.
Caddy applies header_up deletions *after* sets, so the tag we set was immediately
stripped: the gateway never saw it, and a decoy hit (e.g. GET /.env) fell through
to the gateway's /app redirect (308) instead of tripping the honeypot. Drop the
delete — the bare set already replaces any client-supplied value. The real
endpoints keep stripping the header in the @gateway block (delete-only, no
conflicting set). Caught on the live test contour (no caddy locally).

deploy/caddy/Caddyfile

@@ -49,14 +49,15 @@
 	}
 
 	# Honeypot decoy paths: classic vulnerability-scanner bait no real client ever
-	# requests. Route them to the gateway tagged with X-Scrabble-Honeypot so it logs
-	# the scanner hit and (in prod) bans the source IP. The inbound header is
-	# stripped first so a client cannot pre-set it — and even if it did, it would
-	# only ban itself. Keep this list in sync with no legitimate landing/app path.
+	# requests. Route them to the gateway tagged with X-Scrabble-Honeypot — the set
+	# replaces any client-supplied value — so it logs the scanner hit and (in prod)
+	# bans the source IP. (A delete + set in one block would not work: Caddy applies
+	# header_up deletions after sets, which would strip the tag we just set; the real
+	# endpoints instead strip the header in the @gateway block above.) Keep this list
+	# disjoint from every legitimate landing/app path.
 	@honeypot path /.env /.git /.git/* /.aws/* /wp-login.php /wp-admin /wp-admin/* /phpmyadmin /phpmyadmin/*
 	handle @honeypot {
 		reverse_proxy gateway:8081 {
-			header_up -X-Scrabble-Honeypot
 			header_up X-Scrabble-Honeypot 1
 		}
 	}