[feature] key vault: env names, pb key run, and MCP rules that make an agent look here first

[YJack0000]

Why

The vault holds ~65 keys, yet an agent working on this machine never looked in patchbay when a task needed an env var or API key — it asked the user, wrote a placeholder, or said "missing". Two causes:

1. The MCP instructions and tool descriptions only taught storing, never looking up — and an agent that did look dead-ended, because get_key is gated and there was no way to use a key without reading it.
2. Keys were named only by slug id (cf-gh-actions-deploy), with no structured link to the variable name code reads (CLOUDFLARE_API_TOKEN). That link lived as prose inside purposes.

What

• KeyEntry.env — the environment variable a key is exposed as, validated UPPER_SNAKE_CASE (refusals spell the corrected name). Optional; two entries may share one. Old keys.json parses unchanged. The manifest's KeyRecord carries it too.
• Naming convention (docs + MCP instructions): use the name code already reads; otherwise <PROVIDER>_<THING>_<KIND>.
• pb key run <id>... [--as NAME=id] -- <cmd> — inject keys into one child process; the value goes keychain → child, never stdout/log/argv/model context.
• pb key edit <id> — metadata only, for backfilling env on existing entries.
• pb key list --provider/--env/--grep + ENV column.
• MCP: store_key.env, list_keys filters, update_key (metadata, ungated), resolve_env_vars (give it the names code reads; answers which the machine can supply and the exact pb key run / pb env run command). Two new instruction rules: LOOK HERE BEFORE ASKING FOR A CREDENTIAL and NAME THE VARIABLE.
• Panel: env field in the add form and an env column.

Verification

Locally: cargo fmt --check, cargo clippy --workspace --all-targets --locked -- -D warnings, cargo test --workspace --locked (core 649, cli 85, mcp 51), bun run build, tauri-crate clippy — all clean.

[github-actions]

✅ SonarQube Quality Gate passed — pathorsAI_patchbay

0 open issues on this PR.