fix(caddy): wrap actuator block in handle so it takes precedence over catch-all

Closes #512.

The previous `(block_actuator)` snippet emitted `respond @actuator 404`
at the top level of each archive vhost. But each vhost also has a
catch-all `handle { reverse_proxy ... }` that matches /actuator/*
too. Caddy's `handle` blocks are mutually exclusive — once one matches,
the request never reaches a top-level `respond`. So /actuator/health
was being proxied to the backend, which 302s to /login.

Wrap the actuator response in its own `handle /actuator/*` block.
Caddy sorts `handle` blocks by path specificity, so /actuator/* wins
over the catch-all and the 404 is actually returned.

Verified with `caddy validate` against the caddy:2 image.

Also unblocks the nightly.yml smoke test's `/actuator/health → 404`
assertion, which has been failing since the first staging deploy.

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

infra/caddy/Caddyfile

@@ -31,8 +31,16 @@
 	# in application.yaml, /actuator/* is unreachable externally. The internal
 	# Prometheus scrape (future) talks to the backend directly on the docker
 	# network, not via Caddy.
-	@actuator path /actuator/*
+	#
-	respond @actuator 404
+	# Why a `handle` block and not a top-level `respond @matcher`: each archive
+	# vhost has a catch-all `handle { reverse_proxy ... }` that matches every
+	# path including /actuator/*, and Caddy's `handle` blocks are mutually
+	# exclusive. Without our own `handle /actuator/*` the catch-all wins, the
+	# request is proxied to the backend, and Spring Security 302s to /login
+	# instead of Caddy returning 404. See #512.
+	handle /actuator/* {
+		respond 404
+	}
 }
 
 (access_log) {