fix(worker): the Valkey pi-dispatch starts gets a per-deployment password (#468)

[edgehero]

Closes #468

What was wrong

The Valkey pi-dispatch starts (the Quadlet unit, the compose file and up's docker run) had no password. Loopback is shared by every account on a host, so any local account could read another account's queue (task text, repository names), enqueue jobs that account's worker would run with its provider key, or wipe it. #464 stops accidents; this stops a co-tenant who connects on purpose.

Change

• A per-deployment password, VALKEY_PASSWORD, in .env. A separate key, not inside VALKEY_URL, because doctor prints the URL, the panel's pointer stores it and refusals quote it. init writes one and creates .env at 0600; service install and up add one when missing, never over a value, and narrow .env to its owner. None is generated for a shared Valkey (PI_VALKEY_SHARED) or an operator's own VALKEY_URL, which are left as they are.
• Never on a command line. Measured on both VMs: the image's PID 1 (tini) keeps its whole argv, so valkey-server --requirepass X shows X in /proc/<pid>/cmdline to every account for as long as the container runs, and the image's VALKEY_EXTRA_FLAGS appends to that same argv. The password reaches the container in its environment (a 0600 ~/.config/pi-dispatch/valkey.env for the Quadlet unit, --env-file .env for compose, the docker CLI's own environment for up), and one start script hands it to valkey-server - as config on stdin and unsets it. The health check requires PONG with REDISCLI_AUTH, since a bare valkey-cli ping exits 0 on NOAUTH (measured).
• Clients. parseConnection alone attaches the credential (the URL's own, then VALKEY_PASSWORD), for every client through a second account on one host: shared default jobs dir, podman after linger off, and a half-written service install #464's one connection function. A Valkey that refuses the credential makes the worker exit 2 and the CLI, receiver and doctor refuse, naming the key. The value is never logged; VALKEY_PASSWORD joins the worker-only secrets, so it can never reach a job container.
• Upgrade. A loopback Valkey without a password is a doctor warning naming the step. service install --force restarts the Quadlet Valkey with the password (the AOF volume is kept) and then the running worker and receiver; up does the same for docker, warning that a running job is interrupted. doctor itself starts no Valkey: by the doctor judges many service keys from its shell while the service reads them from .env #471 rule it hands no program anything from .env, so its fix line names pi-dispatch up, and its password check is in-process.
• One owner per Valkey. A container or volume counts as this deployment's only when it provably is: up labels what it creates with the deployment folder; an unlabelled container counts only when it publishes this deployment's port; an unlabelled volume is adopted only on an explicit yes (never --yes alone), after its pi-dispatch:owner marker is read in a container with no network, and the adoption is recorded in the folder. Nothing stops, removes or starts beside another deployment's Valkey or on its volume.
• The kill switch. The CLI and the panel read VALKEY_URL like the password. On a shell/.env disagreement pause pauses both queues, status shows both, and resume and cancel refuse until --valkey-url names one. URLs print without userinfo.
• Compose publishes Valkey on VALKEY_URL's port (PI_VALKEY_PORT, written into .env for a non-default port). The wizard keeps its old compose project name with -p, and when up's Valkey exists it hands that volume to compose (pull first, every exit code checked, the way back named), so worker and receiver share one queue.
• Found on the way: a password in VALKEY_URL reached the client still percent-encoded; the .env writer's temp file was world-readable until its chmod; up's docker Valkey step ignored VALKEY_URL's port; and the wizard's compose copy resolved its relative paths outside the deployment folder. All four are fixed, and the admin panel's pause and resume now follow the CLI's rule.

Specs

REQ-DEPLOYMENT-BOOTSTRAP, DES-PODMAN-STACK-AS-QUADLET-UNITS, DES-WORKER-ON-HOST, DES-FIRST-RUN-SETUP-WIZARD, INT-DEPLOYMENT-POINTER-CONTRACT; the others UNCHANGED, checked in the rows.

Verification

• Full suite in CI posture: fail 0. 31 mutations, all killed.
• pd-fedora (Podman 5.8.1) and pd-ubuntu (4.9.3), two fresh accounts each: a fresh install runs a job; another account's PING, KEYS and FLUSHALL get NOAUTH; no command line on the host carried the password during install or at rest; an upgrade from a passwordless deployment kept its queue (marker key and 3 paused jobs survived and completed); a shared Valkey without the password is refused by name. Compose was checked on Fedora through root's Podman socket; Ubuntu has no compose.