feat(errors): expose upstream provider errors as structured JSON

[Destynova2]

Fidelity gap (from the competitive analysis)

The analysis flags "provider error detail lost" — Envoy turning a structured
provider error into an empty HTTP 500.

grob is already ahead: it forwards the verbatim upstream status and the
provider body (error.rs ProviderUpstream). But the body reached the client
only as a message string, often prefixed ("anthropic API error: {…}"), so a
client had to re-parse a blob to read the provider's own error.type/code.

Change

into_response now extracts the first embedded JSON object/array from the body
and attaches it as error.upstream_error, structured, alongside the existing
message / provider / upstream_status:

{
  "error": {
    "type": "error",
    "message": "anthropic API error: {…}",
    "provider": "anthropic",
    "upstream_status": 429,
    "upstream_error": { "type": "error", "error": { "type": "rate_limit_error", "message": "slow down" } }
  }
}

Additive and backward compatible — clients reading message are unaffected;
agents that branch on the provider's error type now can, without string-parsing.

Tests

• extract_leading_json_handles_prefix_pure_and_none — prefixed body, pure JSON, trailing junk, and no-JSON.
• provider_upstream_forwards_status_and_structured_error — 429 forwarded verbatim + parseable upstream_error.
• cargo test --lib server::error — 42 passed.

Part of the fidelity sweep (feeds #484).

🤖 Generated with Claude Code