fix(init,up): the no-clone quickstart starts its egress proxy (#480)

[edgehero]

Closes #480.

The no-clone quickstart did not produce a working deployment. In an empty folder, npx @edgehero/pi-dispatch up skipped the egress proxy (deploy/egress-proxy.conf is not here), and with the egress policy on by default every job was then refused before it spent. up's own advice to run init again could not help, because init never wrote that file. /dispatch setup had the same hole: its up pass ran before it copied any deploy/ file in. Only a clone worked.

• init writes deploy/egress-proxy.conf, a byte for byte copy of the package's own file, create only, and lists it. up then starts the proxy on a fresh folder, and doctor's check that both proxy files are present passes.
• Every init scaffold is written create only (wx), so nothing that exists is written through, a dangling symlink included; that is reported as kept. init refuses a deploy/ that is a symlink or not a directory, and a directory where any scaffold's file belongs: it writes nothing there, says so beside the list of what it did write, and exits 1.
• up goes on past an init that refused or threw, says so and names it in its summary (a file named deploy used to abort up after the image pull). A directory at either proxy file is never treated as the file: up starts no proxy on it, and doctor fails naming it.
• init's Docker ladder names only files the folder has. Step 2 is pi-dispatch up, which starts Valkey and the egress proxy (unless PI_EGRESS=0); the old compose command needed a clone and never started the proxy. The podman ladder links the guide's URL instead of a path the folder does not have.
• up runs init without its ladder (steps: false), so it no longer prints instructions to do what it is about to do. The created/kept lines stay.
• The file column is as wide as the longest name.
• Remedies name pi-dispatch up, and compose only where it is right:
  • The egress-proxy-down refusal comment, the sandbox's network hint and doctor's proxy fix line name pi-dispatch up from the deployment folder and no compose line. Only up knows the folder; a compose line printed without it would, in a folder /dispatch setup laid out, also start compose's valkey under project deploy. A proxy PI_EGRESS_PROXY names is the operator's to start, and the comment and the sandbox say so. Reason tokens, log events and the run record are unchanged.
  • Every later or fallback compose line up prints (declined Valkey or proxy, failed volume create or container start, an open Valkey it did not start) appears only where the folder holds deploy/docker-compose.yml; otherwise it names pi-dispatch up again.
  • The "could not reach Valkey" hint in the CLI, cancel, service restart and the panel names pi-dispatch up only for a loopback VALKEY_URL, and otherwise asks whether the Valkey at that host is running.
  • The worker unit template's Valkey comment names pi-dispatch up (deploy/worker.service and its worker/deploy mirror, byte identical).
  • The wizard's skipped-receiver note names no receiver container on the podman venue, and its create-only copy says "kept as it is" neutrally. setup github's closing steps offer the compose profile only for a folder holding the file.
  • A check in up.test.mjs requires --env-file on every compose command outside a comment in worker/src, receiver/src and admin/src (flags in any order, docker-compose too, its own judgement tested on sample lines), and names each prose mention; composeArgs is pinned to carry --env-file .env.
• Docs: docs/egress.md's one-time steps are pi-dispatch up then doctor; the forge docs' receiver-in-a-container option and docs/podman.md say the compose file comes with a clone or /dispatch setup.

REQ-DEPLOYMENT-BOOTSTRAP and INT-EGRESS-POLICY-CONTRACT amended with revision rows. Every new test mutation checked. Full suite: 5237 tests, 0 fail.

Not in this PR: a folder copy of egress-proxy.conf is never refreshed on upgrade (#484).