v0.3.3: separate fast backoff for connectivity errors vs rate-limiting

Live evidence: after the machine sat idle for a few hours, requests
failed with connection/decode errors (stale keep-alive connections
surviving sleep/wake is the leading theory) and self-healed within a
few attempts -- but at the 429 backoff's pace (minutes between
retries), a hiccup that resolves in seconds looked like the widget
being broken for a long stretch. Only an actual HTTP 429 gets the
cautious rate-limit schedule now; network errors, unparseable
responses, and token problems get a fast 5s-60s schedule instead, and
a network-transport-level failure specifically also rebuilds the HTTP
client before the next attempt.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>