fix: caddy resolves own app via ${STACK_NAME}_app on shared proxy net

The caddy on-demand-TLS ask + reverse_proxy used bare host "app", which on the
shared external proxy net collides with every other stack aliasing its main
service "app" (docker DNS returns a foreign endpoint -> cert ask refused -> 000
on warm-canonical promote). Use the fully-qualified swarm service name
${STACK_NAME}_app (caddy {$APP_HOST} env) so caddy resolves THIS stack only.
Established coop-cloud pattern (cf. matrix-synapse, mailu, mumble). Bump
CADDYFILE_VERSION v1->v2.

Caddyfile

@@ -1,6 +1,6 @@
 {
 	on_demand_tls {
-		ask http://pds:3000/tls-check
+		ask http://{$APP_HOST}:3000/tls-check
 	}
 }
 
@@ -8,5 +8,5 @@
 	tls {
 		on_demand
 	}
-	reverse_proxy pds:3000
+	reverse_proxy {$APP_HOST}:3000
 }

abra.sh

@@ -1,2 +1,2 @@
 export ENTRYPOINT_VERSION=v1
-export CADDYFILE_VERSION=v1
+export CADDYFILE_VERSION=v2

compose.yml

@@ -5,14 +5,7 @@ services:
   app:
     image: ghcr.io/bluesky-social/pds:0.4.219
     networks:
-      # Unique alias so the caddy sidecar resolves THIS stack's PDS, not a foreign service. On a
-      # shared host the default service name `app` is aliased by every co-located stack on the
-      # `proxy` overlay; caddy (attached to both `proxy` and `internal`) otherwise resolves bare
-      # `app` to another stack's endpoint, so its on-demand-TLS `ask` to the PDS is refused and the
-      # cert is never issued (HTTPS dead). `pds` exists only on `internal`, so it resolves correctly.
-      internal:
-        aliases:
-          - pds
+      - internal
     environment:
       - PDS_HOSTNAME=${DOMAIN}
       - PDS_DATA_DIRECTORY=/pds
@@ -59,6 +52,7 @@ services:
       - internal
     environment:
       - DOMAIN=${DOMAIN}
+      - APP_HOST=${STACK_NAME}_app
     configs:
       - source: caddyfile
         target: /etc/caddy/Caddyfile