Permanently eliminate the "$X variable not set" warning, and fix Caddy auto-HTTPS on private IPs

Two separate leaks were causing the same cosmetic-but-annoying warning to
survive every previous fix attempt:

1. Compose's own `secrets:` block reads the referenced file's *content*
   as part of its config model, and applies the same interpolation
   warning to it — even with DB_PASSWORD fully removed from every ${VAR}
   and --env-file path. Switched from Compose's native `secrets:` to plain
   bind mounts at the same /run/secrets/* paths: a bind mount only ever
   touches the file's path, never its content, so it's immune. (Verified
   this precisely with an isolated repro before rolling it out — the two
   mechanisms behave differently even though they look equivalent.)

2. caddy's `env_file: .env.staging` (a leftover from the since-removed
   basic-auth setup) loaded the *raw*, unfiltered env file directly,
   bypassing deploy.sh/backup.sh/restore.sh's filtered-copy mechanism
   entirely. Caddy only ever needed SITE_DOMAIN; switched to passing that
   one value directly instead of the whole file.

Also fixed Caddyfile.staging: the site address had no explicit scheme, so
Caddy's automatic-HTTPS logic still applied to a private IP (registering
its own internal CA and redirecting HTTP->HTTPS) — not the "plain HTTP
only" behavior I'd assumed and told the user earlier. Prefixed with
`http://` to genuinely disable automatic HTTPS for this LAN-only box.

Verified end-to-end: fresh deploy with dollar-sign DB passwords produces
zero warnings, serves HTTP 200 on plain http:// with no redirect, and the
DB connection genuinely authenticates.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docker-compose.production.yml

@@ -16,8 +16,8 @@ services:
     ports:
       - "80:80"
       - "443:443"
-    env_file:
-      - .env.production
+    environment:
+      SITE_DOMAIN: ${SITE_DOMAIN}
     volumes:
       - ./docker/caddy/Caddyfile.production:/etc/caddy/Caddyfile:ro
       - wp_core:/var/www/html:ro