Fix Authelia protection being dead code — reverse_proxy ran before the auth check

Both Caddy site block generators (the shared configure_caddy_for_service
helper, and asterisk-digital-ocean.sh's own inline template) wrote
reverse_proxy before the forward_auth/import authelia block. Caddy
doesn't reorder repeats of the same directive within a block — forward_auth
and reverse_proxy are the same directive family internally, so they run in
the order written. With reverse_proxy first, it handled and terminated
every request immediately; the auth check written after it never ran at
all. Full bypass on every domain using either generator with Authelia
protection, regardless of how correct the Authelia access_control rules
themselves were — confirmed live against a config that was otherwise
completely correct (default_policy: deny, explicit wildcard rule covering
the affected domain).

Affects every service that's ever passed `import authelia` or a
forward_auth block through configure_caddy_for_service (asterisk.sh,
wolf-pair.sh, and any future caller), plus asterisk-digital-ocean.sh's
own site block.

Moved the auth block before reverse_proxy in both generators.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015X1jRGHwrvovz2qkhKfDZi

CLAUDE.md

@@ -159,6 +159,20 @@ reloads Caddy. No-ops silently if Caddy isn't installed. The fourth argument
 is an optional string inserted verbatim inside the Caddy site block (use it
 for `import authelia` or custom matchers).
 
+The function places that block **before** `reverse_proxy` in the generated
+site block — don't reorder this. `forward_auth` (what `import authelia`
+expands to) is the same directive family as `reverse_proxy` internally, and
+Caddy doesn't reorder repeats of the same directive within a block; it runs
+them in the order they're written. `reverse_proxy` written first would
+handle and terminate every request immediately, making an auth check
+written after it dead code that never runs — full bypass regardless of what
+the auth server's own access-control rules say. Confirmed live: this was
+the actual cause of a "Caddy proxies fine but Authelia never prompts for
+login" bug, on a site block that otherwise looked completely correct. If a
+service builds its own site block instead of using this helper (e.g.
+`services/asterisk-digital-ocean.sh` does, deliberately, see its own
+comment for why), put its auth block first there too.
+
 Sets two out-params (not `local` — read them after the call returns) so the
 caller can tell whether Caddy actually ended up fronting the service: