fix(client)!: apply no response-header timeout by default

[Benehiko]

Problem

The Go client defaults ResponseHeaderTimeout to 1 second (DefaultClientResponseHeaderTimeout). Any request where the daemon takes more than a second to start responding fails at the transport layer — and a request can legitimately block far longer than that on user interaction daemon-side: a store unlock, an authorization prompt, or a plugin waiting on input.

The request timeout already defaults to 0 (no limit) for exactly this reason, and the docker pass CLI already overrides both timeouts to 0 when it builds its client. Every other consumer of the SDK silently inherits the 1s cliff unless they know to call WithResponseTimeout(0) — an internal SDK consumer just hit this.

Change

DefaultClientResponseHeaderTimeout is now 0 (no limit), matching the request-timeout default. Doc comments on WithResponseTimeout and the transport construction updated to match.

Consumers that pass explicit timeouts are unaffected; WithTimeout / WithResponseTimeout still apply a hard bound, as does a per-call context deadline.

Testing

• go build ./... and go test ./... in the x, client, and plugin modules — all pass.

🤖 Generated with Claude Code

[docker-agent]

Assessment: 🟢 APPROVE

The change is correct and well-reasoned. DefaultClientResponseHeaderTimeout was causing real failures for legitimate slow-start interactions (store unlock, auth prompts, plugin input — referenced in wield#109). Setting it to 0 aligns with the existing DefaultClientRequestTimeout = 0 design, matches what the docker pass CLI already explicitly does, and correctly reflects the secrets-engine domain where blocking on user interaction is expected.

What was checked:

• The behavioral change from time.Second → time.Duration(0) is intentional and correctly implemented via http.Transport.ResponseHeaderTimeout
• Both RequestTimeout and ResponseHeaderTimeout now default to 0, consistent with each other and the PR rationale
• Updated doc comments in WithResponseTimeout and the New() inline comment accurately describe the new default and correctly point callers to WithResponseTimeout or per-call context deadlines as opt-in bounds
• No compilation issues; API contract for WithResponseTimeout (rejects negatives, 0 = no limit) is unchanged
• The concern about non-interactive callers losing an implicit 1s safety net was evaluated and found to be a pre-existing design tradeoff the PR explicitly and correctly addresses — not a regression

No actionable issues found.

[docker-agent]

Assessment: 🟢 APPROVE

The PR makes three coherent, self-consistent changes:

1. x/api/defaults.go — DefaultClientResponseHeaderTimeout changed from time.Second to time.Duration(0) (no limit).
2. client/client.go — Doc comments updated to reflect the new default; no logic changes.
3. plugins/pass/commands/run.go — Explicit WithResponseTimeout(0) override removed (now redundant given the new default); corresponding test updated.

No logic errors, security issues, resource leaks, or concurrency problems were found in the introduced changes. The change correctly propagates through the call chain, and the removal of the now-redundant override in the pass plugin is safe.