anubis: bot-challenge proxy in front of the guarded vhosts (two-tier chain)

Bots and AI scrapers hit the SSO-fronted vhosts and eat Authentik auth
work for 403s. Anubis verifies clients first: DENY for known AI scraper
UAs, JS challenge for everyone else; verified traffic resumes the normal
Authentik forward_auth chain on Caddy's internal listener (:8016).

Chain: client -> Caddy (TLS) -> Anubis :8923 (verify) -> Caddy :8016
(auth + routing resumes; Host survives both hops) -> app. Reverse-proxy
through Anubis, not forward_auth: at the pinned tag a CHALLENGE answers
HTTP 200 + HTML, and forward_auth treats 200 as "authenticated" — the
page would pass through unchallenged. Exempt by construction (never
routed through Anubis): plex (plain HTTP legacy), auth.* (IdP login
must be reachable ungated), gitea (git smart-HTTP clients cannot solve
JS challenges), and every app with its own login.

Pinned ghcr.io/TecharoHQ/anubis:v1.13.0 — the tag was source-verified
before pinning: at this tag the policy parser is JSON-only with a
minimal bots[] schema (no imports, no CEL expressions), flags are the
config surface via flagenv (TARGET/POLICY_FNAME map to --target/
--policy-fname), and the image's exec-form HEALTHCHECK is inherited by
the quadlet unit (dodges the v1 generator's HealthCmd space-split quirk).

Rollback nuance: stopping anubis 502s everything behind the chain (the
public listeners proxy through it); a true rollback is reverting the
Caddyfile and redeploying, not just systemctl --user stop anubis.

tests/homepage_caddy.bats

@@ -1,8 +1,9 @@
 #!/usr/bin/env bats
-# Seam: the homepage site block in dankclaw/Caddyfile. It serves /srv/homepage
-# from the naked domain (franksdank.cloud) and www. Authentication is via
-# Caddy forward_auth (Authentik SSO) — the basicauth hashes were retired in
-# favor of the unified Authentik login. caddy is not on the dev box, so the
+# Seam: the homepage site block in dankclaw/Caddyfile. Since the Anubis
+# rollout the naked domain + www are guarded vhosts: the public listener
+# proxies everything through Anubis (bot challenge), and the Authentik
+# forward_auth for SSO runs on Caddy's internal listener (http://:8016)
+# after Anubis has verified the client. caddy is not on the dev box, so the
 # tests assert the structure statically.
 
 load helpers
@@ -26,13 +27,19 @@ setup() {
 @test "the shared data + assets are served to any authenticated user" {
     # The data (services.json, status.json) and assets are fetched by both the
     # user page and the admin page. With forward_auth, any authenticated user
-    # can access them (the browser's Authentik session covers the fetch).
+    # can access them (the browser's Authentik session covers these fetches).
     grep -qE "@data[[:space:]]+path[[:space:]]+/services\.json[[:space:]]+/status\.json" "$CADDY"
     grep -qE "handle[[:space:]]+@data" "$CADDY"
 }
 
-@test "the homepage vhost uses forward_auth (Authentik SSO)" {
+@test "the homepage vhost chains Anubis (public) before Authentik SSO (internal listener)" {
+    # Public listener: the naked domain proxies everything through Anubis.
     local block
     block=$(awk '/^franksdank\.cloud[[:space:]]/,/^}/' "$CADDY")
-    echo "$block" | grep -q 'forward_auth'
+    echo "$block" | grep -q 'reverse_proxy anubis:8923'
+    # The SSO check itself now runs on the internal listener that Anubis
+    # forwards accepted traffic to; Host survives the hop, so per-vhost
+    # routing (and with it forward_auth) resumes there.
+    grep -q 'http://:8016' "$CADDY"
+    awk '/^http:\/\/:8016/,/^\}/' "$CADDY" | grep -q 'forward_auth authentik-server:9000'
 }