docker deploy provider: work when core runs in a container

[irisfeng]

Problem

qm up on the docker backend runs every service — including core — as a container on one shared stack network, with core's /data as a named volume and (when the local sandbox backend is active) the docker CLI plus DOCKER_HOST/QM_CORE_CONTAINER wired into core. That is the shape self-hosted deployments get out of the box, and the docker deploy provider (the default DEPLOY_PROVIDER) assumes the opposite of it in two places:

1. Snapshot bind mount. apply ran the app container with -v ${snapshotDir}:/app:ro. The snapshot lives inside core's container/volume; the host daemon resolves that path against the host filesystem and auto-creates an empty directory there — every published app starts with no code and dies on MODULE_NOT_FOUND. Verified on a live deployment: the host-side directory is empty, the core-container-side one has the app.
2. Loopback endpoint. apply published the app port on 127.0.0.1 and returned {host: "127.0.0.1"}. A containerized core dialing loopback reaches itself, never the app — so even a running app was unreachable.

Fix

• Snapshot materialization becomes docker create → docker cp <snapshotDir>/. <container>:/app → docker start. docker cp streams through the daemon API from wherever the docker CLI runs, so no filesystem boundary is crossed — correct for container-run and host-run core. The copy gets a generous explicit timeout (snapshots routinely carry node_modules; the 60s default would kill large copies mid-stream).
• Shared-network mode. A new DEPLOY_DOCKER_NETWORK env names the network core already sits on. qm up sets it for core alongside DOCKER_HOST/QM_CORE_CONTAINER — those three now come from one shared helper so the serviceEnv and dockerServiceEnv code paths cannot drift apart again. Each app container joins that network with --network-alias <container-name> and no host port publishing; the endpoint becomes {host: <container-name>, port: APP_PORT}, resolved through docker's embedded DNS. destroy never removes a network it did not create. Deployments stored with a pre-fix loopback endpoint resolve as absent so the deploy service re-materializes them onto the shared network.
• Without DEPLOY_DOCKER_NETWORK, the provider keeps the previous per-deployment network + published loopback port shape, which is correct for core running directly on the host.

Endpoint consumers already treat host as an opaque hostname (the proxy dials host:port from core), so no consumer changes were needed.

Tests

Provider: shared-mode sequence (create → cp → start, no -v/-p, alias endpoint, network untouched on destroy), copy-failure and start-failure cleanup, stale-loopback re-materialization, plus new pins on the fallback path (loopback publish + snapshot copy). CLI: the existing "host daemon coordinates only into core" test now also pins DEPLOY_DOCKER_NETWORK. Full provider suite 9/9, auth-broker 11/11, CLI suite identical to the pre-change baseline (same env-gated failures).

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}