fix(routing): unique pds alias so caddy resolves THIS stack's PDS on shared proxy

The caddy sidecar uses on-demand TLS and asks http://app:3000/tls-check before issuing a cert.
On a shared host every co-located stack aliases its main service 'app' on the 'proxy' overlay;
caddy (on both proxy+internal) resolves bare 'app' to a FOREIGN stack's endpoint, so the tls-check
connection is refused, no cert is issued, and the PDS is unreachable over HTTPS (xrpc/_health=000).
Give the PDS a unique 'pds' alias on the internal network and point caddy's reverse_proxy +
on_demand_tls ask at it; 'pds' exists only on internal, so it always resolves to this stack's PDS.
Service name stays 'app' (no downstream breakage).

compose.yml

@@ -2,10 +2,17 @@
 version: "3.8"
 
 services:
-  pds:
+  app:
     image: ghcr.io/bluesky-social/pds:0.4.219
     networks:
-      - internal
+      # 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
     environment:
       - PDS_HOSTNAME=${DOMAIN}
       - PDS_DATA_DIRECTORY=/pds