v0.9.14: http_request tool — arbitrary method/headers/body with secret references, replacing bash curl for APIs

Source: tool-surface survey 2026-09-15 (comparison against ~15 harnesses in `refs/`). Verified in source: `tools/web/fetch.rs` is hardcoded GET — no method, body, or request headers anywhere in the web family.

Today the only way for the model to make an authenticated API call is `bash curl` with the token on the command line. Two real product defects, not just inconvenience:

- Bearer tokens typed into the command line land verbatim in the journaled transcript.
- `curl` sits on the network-approval list (`shell.rs`), adding friction to a path the "connected apps" promise needs to be good at.

## Proposal

An `http_request` tool: arbitrary method, headers, body; response-size caps; header redaction in results; per-host policy reusing the existing web guard machinery. Ideally a secret-reference syntax (`"Authorization": "$secret:linear"`) that pulls from `crates/secrets` without exposing the value to the transcript.

Serves the connected-apps PRD promise and "control and receipts legible" in one tool. Pairs with the write-only-secrets GPUI route gap already named in DIRECTION §10.

Start by reading tools/web/fetch.rs, shell.rs, and crates/secrets, then review the web guard machinery and DIRECTION §10. The proposal calls for a new http_request tool with arbitrary methods, headers, bodies, response caps, redaction, per-host policy, and secret references. Done means these requirements are designed and implemented without exposing secrets in transcripts.

Written by the indexing model from the issue text.