[Bug] One transient advisor failure permanently latches the tool off for the whole session; distinct error causes flattened to generic "unavailable"

Summary

A single failed advisor call permanently disables the advisor tool for the rest of the session, even when the underlying failure is transient (rate pressure / load). The client surfaces one generic latched string — The advisor tool is unavailable. Do not try to use it again. — and never retries, so long-running sessions lose the advisor entirely after one bad moment.

Environment

• Claude Code 2.1.173 (also observed on 2.1.16x–2.1.17x)
• Linux (WSL2), terminal CLI
• Main model: Fable 5 and Opus 4.8 sessions both affected

Reproduction

1. Run several concurrent Claude Code sessions on one account (e.g. an orchestrator session plus 4–6 worker sessions in tmux panes — typical subagent/fanout workload).
2. In any session, have the model call advisor() while the account is under concurrent load.
3. The call fails with Advisor unavailable (unavailable).
4. Any later advisor() call in that session — including minutes/hours later when the account is idle — immediately returns The advisor tool is unavailable. Do not try to use it again. without attempting the call.

Observed 4 independent latches across 4 different sessions in one afternoon under this workload. A fresh session on the same account immediately has a working advisor again, confirming the failure is per-session client state, not account/server state.

Expected

• Transient failures (rate-limit / overload class) should be retryable — at minimum on the next explicit advisor() call, ideally with backoff. Only genuinely permanent conditions (e.g. unsupported model pairing) should latch for the session.
• The surfaced error should preserve the underlying cause. The API distinguishes advisor_tool_result error codes (e.g. prompt_too_long, too_many_requests, overloaded, execution_time_exceeded, unavailable), but the client flattens all of them into the same latched "unavailable" string, which makes the failure look random and undiagnosable from the transcript.

Actual

• One transient failure → advisor dead for the session lifetime.
• All error causes collapse into one generic string (related: #66784, which reports the same generic wording for the model-pairing case).

Impact

Long-running orchestration sessions (the sessions that most need a second-opinion pass) effectively cannot rely on the advisor: the heavier the (legitimate) concurrent workload, the more certain the advisor is to latch off early in the session. Current workarounds are restarting the session or wiring an external review fallback.

Suggested fix

Treat too_many_requests / overloaded / unavailable-class results as retryable (clear the latch on next call or after a cooldown), latch only on permanent conditions, and include the specific error code in the surfaced message.