fix(deploy): point DYNDNS_DATA/DYNDNS_LOGS at the container mount paths

The compose file was passing ${STEVEDORE_DATA} — the HOST path —
straight through to DYNDNS_DATA inside the container. That path doesn't
exist in the container (the volume is mounted at /data), so any
MkdirAll + write under cfg.DataDir succeeded on the container's
writable layer and got destroyed on every rebuild. MTProto secrets
visibly regenerated after each deploy because of this.

Use /data and /var/log/dyndns — the static container-side paths that
match the bind mounts further down in the file.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: jonnyzzz

docker-compose.yaml

@@ -79,9 +79,13 @@ services:
       - TELEGRAM_BOT_TOKEN=${TELEGRAM_BOT_TOKEN:-}
       - TELEGRAM_BOT_CHAT_IDS=${TELEGRAM_BOT_CHAT_IDS:-}
 
-      # Internal paths (set by Stevedore or use defaults for local dev)
-      - DYNDNS_DATA=${STEVEDORE_DATA:-./data}
-      - DYNDNS_LOGS=${STEVEDORE_LOGS:-./logs}
+      # Internal paths — must match the container mount points below, not
+      # the host paths. DYNDNS_DATA was previously set to ${STEVEDORE_DATA},
+      # which is the HOST path; writes from inside the container to that
+      # path landed on the ephemeral container layer, not on the persistent
+      # volume. MTProto secrets regenerating across rebuilds surfaced this.
+      - DYNDNS_DATA=/data
+      - DYNDNS_LOGS=/var/log/dyndns
 
     volumes:
       # Persistent data - certificates, DNS state