fix(client): classify request timeouts as timeout/exit 4 on all paths

[somanshreddy]

Scope

Surfaces: API (CLI) | Module: HTTP client / error classification

Supersedes #229 (auto-closed when its base #228 merged and the base branch was removed). Review feedback from #229 is addressed here — see commits on this branch.

Summary

A transport-level HTTP timeout was reported with a different error code and exit code depending on whether --wait was passed. It now consistently surfaces as timeout (exit 4) on every path.

Root cause

The same event — the per-request HTTP deadline elapsing before a response arrived — was classified two ways: plain Execute → network_error / exit 1; --wait → timeout / exit 4 via a fragile string-match on the Go error message. So a slow create/upload reported inconsistently, and the --wait detection depended on an error string that could drift.

Fix

Classify the timeout at the source in executeWithContext using net.Error.Timeout() — the robust detector, since http.Client.Timeout's wrapped error does not reliably satisfy errors.Is(err, context.DeadlineExceeded) (exactly why the old path string-matched). Both paths now return timeout / exit 4, and the dead string-match in translateCreateContextError is removed.

Also, from #229 review:

• Write-safe hint (duplicate-create): the timeout hint is method-aware. A GET is safe to retry; a non-GET (create/write) may have committed server-side before the deadline and CLI writes carry no idempotency key, so its hint says "check status before retrying, to avoid a duplicate" — mirroring the poll-deadline guidance.
• Budget in message: the timeout message names the applied per-operation budget (...after 120s) for support triage.
• Retry-layer alignment: shouldRetry also short-circuits on net.Error.Timeout(), so the retry layer and the classifier agree a client timeout isn't retryable.

Scope of impact: a connection-refused / genuine transport failure still returns network_error (exit 1); the --wait poll-window-elapsed path is unchanged.

Breaking change

A plain (non---wait) request timeout now exits 4 instead of 1. The README exit-code table is updated. Diligence: scanned heygen-com for consumers branching on the CLI's network_error / exit 1 — none key on it, so no known internal consumer breaks.

Testing

New tests: a request that exceeds the client timeout surfaces timeout / exit 4; a POST (write) timeout carries the check-status-first hint and names the budget; a GET timeout does not carry create/duplicate guidance. Existing tests still pass: connection-refused → network_error (TestExecute_NetworkError), and the --wait poll-deadline test still yields timeout / exit 4. make lint clean.