Fix real HTTP retry classification and persistent circuit state

[kiku-jw]

Problem

The public API path currently does not support the retry and circuit-breaker behavior that the repository previously described.

Observed on main at 729132a7010b0fcdf2e70ecadb974e92755ba6d0:

• RetryEngine reads error.status_code, while httpx.HTTPStatusError exposes the response status at error.response.status_code.
• A MockTransport reproduction configured for three attempts raises after one HTTP 429 call (calls=1).
• httpx.ConnectError is classified as no-retry.
• The primary /v1/proxy/* path constructs its circuit breaker per incoming request, so state does not persist across requests.
• Existing CI does not exercise the real HTTP client path for these cases.

The public site and README are being narrowed separately so they do not promise behavior before this issue is fixed and demonstrated.

Acceptance

• HTTP 429 and configured retryable 5xx responses perform the configured number of attempts.
• Retry-After is honored from a real httpx.HTTPStatusError response.
• configured transport/connect failures follow an explicit, tested retry policy.
• circuit state persists across incoming proxy requests for the intended tenant/upstream boundary.
• tests cover the real httpx client integration path, not only synthetic exception attributes.
• CI runs the new retry/circuit integration tests.
• a dated reproducible trace can support any restored public reliability claim.

Non-goals

• No benchmark or cost-savings claims without measured evidence.
• No provider-specific failover redesign in this issue.

Tracked from kiku-jw/kikuai-project-map#13.