Revert the ::ffff: peer match: #209 was not a bug

Caddy reports an IPv4 peer as plain IPv4 even on its dual-stack socket, so remote_ip
192.168.64.1 matched all along. The stripping seen came from testing on Tower itself, whose
requests reach the published port as 192.168.1.130, rightly not the tunnel. From
cloudflared's network a forged Access token reaches ipx's check and is refused.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

web/Caddyfile

@@ -2,7 +2,7 @@
 # so the session cookie, live updates and Cloudflare Access work as they did when ipx served it.
 #   IPX_UPSTREAM  where ipx is, host:port            (ipx:8099)
 #   WEB_BIND      where to listen                    (:8080)
-#   TUNNEL_PEER   the one IPv4 address whose Cf-Access-* headers are passed on: where cloudflared's
+#   TUNNEL_PEER   the one address whose Cf-Access-* headers are passed on: where cloudflared's
 #                 requests come from. Nobody else's are, so nobody else can claim to be signed in
 #                 by Cloudflare. Unset passes none.
 {
@@ -13,10 +13,8 @@
 http://{$WEB_BIND::8080} {
 	root * {$WEB_ROOT:/srv}
 
-	# Before anything else, so no page or API call sees them: only ipx sets these. Both forms of
-	# the peer: Caddy listens dual-stack, so an IPv4 peer arrives as ::ffff:a.b.c.d, which the
-	# plain address does not match, and the tunnel's headers were stripped too (#209).
-	@forged not remote_ip {$TUNNEL_PEER:255.255.255.255} ::ffff:{$TUNNEL_PEER:255.255.255.255}
+	# Before anything else, so no page or API call sees them: only ipx sets these.
+	@forged not remote_ip {$TUNNEL_PEER:255.255.255.255}
 	request_header @forged -Cf-Access-Authenticated-User-Email
 	request_header @forged -Cf-Access-Jwt-Assertion