fix(cloud-environment): pages-publish config override can send any vault secret to any host #760

Problem

components/cloud-environment/pages-publish can be driven to send any Key Vault secret the caller can read to any https host, without a permission prompt.

• load_config (lines 119-139) takes ~/.config/pages-publish/config over the Key Vault config whenever that file exists. The only checks are that it is a regular file, owned by the current user, mode 0600. A process running as the user can create such a file.
• parse_config (line 105) accepts any https://<host> as an *_ENDPOINT, and line 108 accepts any [A-Za-z0-9-]{1,127} as a *_TOKEN_SECRET / PRIVATE_ACCESS_*_SECRET name.
• send (lines 164-192) resolves those names through vault-exec and sends the values as Authorization / CF-Access-* headers to the configured endpoint.
• Bash(pages-publish *) is in the permissions floor (components/claude-permissions/claude-permissions.json:50), and vault-exec is not. So an injected agent that can write that one file can exfiltrate an arbitrary vault secret through a pre-approved command it could not run directly.

This applies to cloud sessions today. Once #759 syncs the script to dotfiles, it also applies to local machines, which have more secrets in reach.

Fix

Choose one or more (owner decision):

• Require secret names to start with pages-publish-, so the script can resolve only its own secrets.
• Pin the endpoint hosts (for example a suffix allowlist of melodicsoftware.com), or drop the endpoint keys from the local override.
• Drop the local file override, or accept it only from a path the agent cannot write.

Lower severity, from the same review: line 208 honors TMPDIR, despite the header saying run-time variables are ignored, and PATH selects vault-exec, curl, awk and gitleaks. Either pin them, or correct the comment and the README.

Evidence

The fresh-context security review run while marking #759 ready; line numbers above are at fc34a5c5fb8f5c9ee3312adb70b4ef4501b5455c.