fix: retry transient HTTP failures

[victor0602]

What changed

• Add centralized, bounded retries for transient network failures and HTTP 408, 429, 500, 502, 503, and 504 responses.
• Use exponential backoff with jitter, honor Retry-After, and cap delays.
• Recreate per-attempt timeout signals and safely replay JSON and FormData request bodies.
• Keep permanent HTTP errors fail-fast.

Why

The shared HTTP layer previously made a single attempt, exposing every command and SDK operation to temporary rate limits, service errors, and network instability.

Impact

Transient failures can recover automatically while retry counts and delays remain bounded.

Checks

• bun test — 469 passed
• bun run typecheck
• bun run lint — no errors; one pre-existing test warning
• git diff --check

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[NianJiuZst]

I do not recommend merging this revision yet.

[P1] Do not retry every request method by default. This shared loop replays all POSTs, and the CLI uses it for generation jobs, uploads, and other state-changing operations. If the server commits a paid job but the connection drops (or it returns a retryable 5xx before the client receives confirmation), this sends the POST again and can create duplicate work or charges. A minimal fetch stub that committed before throwing produced sideEffects: 2. Restrict automatic retries to safe/idempotent methods, or require an explicit per-request opt-in backed by a provider idempotency key.

Local verification: typecheck, lint (one pre-existing warning), build, 24 focused tests, and the full suite (469/469) passed. The green replay tests currently encode the unsafe behavior rather than protecting against it.