Fix Caddy reverse-proxy target for host-network services

Caddy runs in its own container on the caddy_net bridge network, so
"localhost" in a Caddyfile site block resolves to Caddy's own
container — never the host, and never a sibling container. That
broke every reverse proxy pointed at a network_mode: host service
(confirmed live with asterisk-do's web admin): once nothing else
(like a forward_auth redirect) intercepted the request first, Caddy
couldn't actually reach the upstream.

- services/caddy.sh: add extra_hosts so host.docker.internal resolves
  inside the Caddy container (Linux Docker needs this explicitly —
  it's automatic only on Docker Desktop).
- lib/common.sh's configure_caddy_for_service: bare-port upstreams
  (its documented "host-network service" case) now target
  host.docker.internal instead of localhost.
- services/asterisk-do.sh: its self-contained Caddy block (doesn't go
  through configure_caddy_for_service) gets the same fix for local
  Caddy, and now correctly targets the droplet's public IP instead of
  localhost for the remote-Caddy snippet case, which had the same bug.

services/asterisk.sh needs no direct change — it already goes through
configure_caddy_for_service, so it inherits the fix.

services/caddy.sh

@@ -267,6 +267,12 @@ services:
       - ACME_AGREE=true
     labels:
       - "io.podman.annotations.label/crowdsec.enable=true"
+    # Lets Caddyfile blocks reach services that use network_mode: host
+    # (e.g. asterisk/asterisk-do) via "host.docker.internal:PORT" — Caddy
+    # itself is on the caddy_net bridge network below, so plain "localhost"
+    # in a site block resolves to Caddy's own container, not the host.
+    extra_hosts:
+      - "host.docker.internal:host-gateway"
     networks:
       - caddy_net