Stop handing StackPilot's own settings to the stacks it deploys (0.66.3)

docker compose ran with StackPilot's whole environment, and compose
resolves ${VAR} from the calling environment before a stack's own .env.
A stack whose compose file says SECRET_KEY: ${SECRET_KEY} therefore ran
with StackPilot's SECRET_KEY instead of the one in its .env — and with
its own again whenever it was started from a shell. AnsiblePilot hit
exactly this: credentials saved under one key became unreadable under
the other, twice.

config.child_env() is os.environ minus every StackPilot setting
(SECRET_KEY, DATA_DIR, STACKS_DIR, PORT, ...); the docker CLI and git
subprocesses now get that instead.

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

README.md

@@ -958,6 +958,12 @@ credentials in the database. Leave it unset and one is generated and written to
 credentials survive restarts — that file is then part of your backup. Setting it
 explicitly always wins and nothing is written.
 
+None of these settings reach the stacks StackPilot deploys. Compose resolves
+`${VAR}` from the calling environment before a stack's own `.env`, so until
+0.66.3 a stack that uses `${SECRET_KEY}` (or `PORT`, `DATA_DIR`, …) ran with
+StackPilot's value instead of its own — and with its own again when started from
+a shell. Anything such a stack encrypted in between was keyed to the wrong one.
+
 The host path for stacks is set via `STACKS_HOST_DIR` in `.env`, and it should
 be **the same path as `STACKS_DIR`** (`/opt/stacks` by default). Compose runs
 inside the backend container, so a stack's relative bind mounts (`./config`) are