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) — wield just hit this (docker/wield#109).

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.