fix(timeout): 120s provisioning deadline so slow provisions don't 409

[mastermanas805]

Problem (live-verified)

The SDK's single client-wide ~30 s HTTP timeout was too tight for synchronous provisioning. Under prod hot-pool contention a fresh Postgres provision exceeds 30 s; the client gave up, the server kept working and held a 60 s in-flight idempotency marker, so the caller's retry hit 409 idempotency_key_in_progress. Raising the client-side timeout to ~120 s fixed it in the field.

Fix

• Provisioning + deploy now default to a 120 s per-request deadline; reads stay at 30 s. The provisioning paths (ProvisionDatabase/Cache/MongoDB/Queue/Storage/Webhook + Deploy) run on a dedicated provisionClient that carries no client-wide Timeout cap; the 120 s budget is enforced per-request via provisionContext. Read calls (list/get/claim/delete/rotate) are unchanged on the existing httpClient.Timeout (30 s), so the guarded read-path timeout tests stay green.
• WithTimeout still overrides — it now governs both the read and provisioning budgets. A WithHTTPClient whose Timeout is explicitly set governs provisioning too (the SDK won't silently widen a caller's deliberate budget to 120 s).
• A tighter caller context.Context deadline is always honoured — provisionContext only lengthens an open-ended context, never overrides a shorter caller deadline.
• The single client-wide cap was the root constraint: http.Client.Timeout is a hard ceiling on every request, so a per-request context deadline alone couldn't extend past 30 s. Splitting into two HTTP clients (sharing the same auth-wrapped transport) is the least-disruptive correct fix and leaves the read-path tests — TestNew_DefaultsAndOptions (Timeout == defaultTimeout) and client_options_test.go's TestWithHTTPClient_PreservesTimeout — untouched.

No 30 s default was intentionally guarded for the provisioning path; the only pinned-30 s tests are read-path and remain valid.

Tests (package instant, run under -race in CI)

• TestProvisioningTimeoutDefaults — pins read=30 s / provision=120 s split + provisionClient.Timeout==0.
• TestProvisioningOutlivesReadCap — behavioral proof: a provision succeeds against a server that stalls past the read-path cap, while a read against the same server times out (scaled to ms; same mechanism as 30 s/120 s).
• TestProvisioningHonorsTighterCallerDeadline, TestWithTimeoutGovernsProvisioning, TestWithHTTPClientTimeoutGovernsProvisioning, TestProvisionContextOpenEndedGetsBudget, TestProvisionContextZeroTimeoutFallsBack, TestProvisionJSONMarshalError.

100% coverage on every added line (provisionContext, provisionJSONWithHeaders, jsonBodyReader, New, WithTimeout all 100%; the only changed line in the shared doWithClient loop body — hc.Do(req) — is covered).

Docs

README Provisioning section gains a "Timeouts: provisioning runs longer than reads" subsection; Client configuration WithTimeout comment updated; CHANGELOG Unreleased/Fixed entry added.

Gate

• go build ./... ✓ go vet ./... ./examples/... ✓
• go test ./... -race -count=1 ✓ (CI's exact command)
• golangci-lint run ./... → 0 issues
• gofmt (real, $GOROOT/bin/gofmt) clean on all authored/edited files
• go test -tags integration -run TestProdIntegration ✓ (read-only prod checks, no regression)

🤖 Generated with Claude Code