Bug

classifyFailoverReasonFromHttpStatus in pi-embedded returns null for HTTP 500, which means:

1. OpenClaw doesn't classify it as a transient error
2. The failover system doesn't trigger
3. No retry, no fallback to the configured fallback model
4. The run just dies with isError=true

Current behavior

The function handles:

• 502, 504 → "timeout" (triggers retry/failover)
• 503 → "timeout" or "overloaded"
• 529 → "overloaded"
• 408 → "timeout"

But skips 500 entirely, returning null.

Expected behavior

HTTP 500 from Anthropic (or any provider) is a transient server-side error. It should be classified as "timeout" to trigger the same retry/failover logic as 502/504.

Proposed fix

// Before:
if (status === 502 || status === 504) return "timeout";

// After:
if (status === 500 || status === 502 || status === 504) return "timeout";

Impact

When Anthropic returns HTTP 500 (which happens occasionally during high load), agents on models with configured fallbacks (e.g., Opus primary → GPT-5.4 fallback) don't failover — the entire run fails instead of gracefully switching to the fallback model.

Reproduction

1. Configure a model with fallbacks in openclaw.json
2. Wait for an Anthropic 500 (or simulate one with a proxy)
3. Observe that the run dies instead of failing over

Workaround

Local patch: sed -i 's#status === 502 || status === 504#status === 500 || status === 502 || status === 504#' dist/pi-embedded-*.js