[Bug]: A thread stopped by a usage limit is labelled Failed, indistinguishable from a crash

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. On a Claude subscription, exhaust the 5-hour window and send a message to a Claude thread. The turn fails with "Claude usage limit reached. Send the message again once the limit resets." (#10321).
2. Look at the thread's row in the sidebar (web) or the thread list (mobile), and at the red banner above the timeline.

Expected behavior

A thread that stopped because the account is out of quota reads as waiting, not broken: the row says something like Limited in the amber tone the other wait states use (Approval, Woke), and the thread banner is a warning, not an error. A user scanning ten threads should tell "this one hit the limit, it will work again at 9:20" from "this one crashed" without opening each.

Actual behavior

The row says Failed in red and the banner is the red error banner, identical to a provider crash or a transport error. Since #8358 and #10321 a usage-limit stop is deliberately a failed turn with a visible message, which is right for the turn state, but the clients have no way to tell the two failures apart: OrchestrationSession carries only lastError (a string) and status: "error", so resolveSidebarThreadStatus (apps/web/src/components/Sidebar.logic.ts) and resolveThreadListV2Status (apps/mobile/src/features/threads/threadListV2.ts) both map every errored session to failed. The adapters already know the difference: the Claude adapter emits the limit as a runtime.error whose payload has a class slot (provider_error today), and #10473 does the same for Codex.

The thread on the left stopped on a limit; the row and banner call it a failure:

Suggested shape, keeping the failed-turn model: add usage_limit to the runtime error class the adapters already send, carry it onto the session as lastErrorClass beside lastError, and let the web sidebar, the mobile list, and the thread banner read it. No change to turn state, retries, or settlement.

Related: #7314 (subagent status stays red after a limit recovery) is the same blindness one level down; #9012 offers the snooze from the same signal.

Impact

Minor bug or occasional failure

Version or commit

main @ 1d1bf5040

Environment

macOS 15, desktop app; Claude Code CLI 2.1.263; server on Linux

Logs or stack traces

No response

Screenshots, recordings, or supporting files

No response

Workaround

Open the thread and read the banner text.

Start by tracing the runtime.error payload and OrchestrationSession's lastError handling, then inspect resolveSidebarThreadStatus in apps/web/src/components/Sidebar.logic.ts and resolveThreadListV2Status in apps/mobile/src/features/threads/threadListV2.ts. Verify how the thread banner consumes the same status. Done means usage-limit errors remain failed turns but display a distinct waiting state and warning treatment in the web sidebar, mobile list, and banner.