fix(http): retry transient gateway status failures

[rudycelekli]

The generic HTTP provider turns 408/500/502/503/504 replies into ordinary response errors and skips its retry loop. A temporary gateway failure thus drops a probe that a permitted retry would recover. Use the shared retryable-status set and ProviderOverloadedError, and include that typed exception in the adapter retry loop.

Validation:

• Five transient-status regressions fail on unchanged main; the HTTP 400 control passes. Eleven local HTTP response controls pass after the fix, covering recovery with one retry and typed exhaustion with zero retries.
• Native provider tests use Python 3.11.15 and the installed SDKs; only owned loopback HTTP or controlled final SDK generation is used. No paid API, live credential or model-quality benchmark.
• Ruff 0.16.9, Bandit, layout validation and all eleven shipped example fixtures pass.
• Advisory provider Mypy retains existing errors in resolver, Bedrock and Hugging Face surfaces; no package-wide typecheck or hosted CI pass is claimed.

Worked CLI customer-support fixture uses an owned HTTP server that returns 503 on the first B07 chat attempt and succeeds on retry. The actual HTTP adapter, inspection and mock judge produce the following selected-run scorecard.

{"provider": "http", "test_id": "B07", "status": "pass", "score": 1.0, "evidence_count": 10, "overall_score": null}

The overall score is null because only one category was selected. CLI examples exit 2 for that selected-run limitation; the public API example returns normally. This validates adapter behavior with synthetic responses, not model quality.