fix(sessions): explain why a session failed on the channel card

[gbasin]

The gap

A failed session card in a channel showed a bare "✕ Failed after 8s" with no cause.

The cause was captured — it reaches the session pane via session_records → FailureNotice. But nothing carried it to the channel:

• session.completed payload had only resultExcerpt, which is derived from result_text — null on failure.
• The session row had no failure column at all, so a cold load had nothing either. (A channel's timeline query excludes thread events, so the completion event never reaches the card.)

Observed in prod: a codex run died on "You've hit your usage limit … try again at Jul 25th, 2026 3:25 AM" and the channel said only that it failed. The actionable part was one click away instead of on the card.

Change

• Migration 084 — sessions.failure_class, sessions.failure_reason.
• Server — persist both from the terminal execution_state frame; carry them on session.completed and on /sync's snapshot rows. A steer clears them (the new turn owns the outcome).
• Shared — fold onto the client Session; mergeSessionEntity preserves them so a snapshot can't erase what the fold explained; status_changed's new-turn branch clears them.
• Render — new failureLine() in centaur-client wraps the existing classifyFailure, preferring the engine's own words over our class summary ("You've hit your usage limit…" beats "The agent hit an error and stopped"). Wired into web + mobile MessageRow.

GET /api/sessions stays lean — these ride /sync's snapshot row only, respecting the existing "stays lean" guard.

Purely additive: with no reason reported, failureLine returns null and callers keep the existing bare "Failed". Falls back to resultText for failures logged before this.

Testing

• pnpm check — lint + typecheck + 2811 unit tests, all green
• pnpm e2e — 120 passed (4.6m)
• New coverage: server end-to-end (frame → row + completion payload), shared fold (including steer-clears-stale-failure), and failureLine unit tests

Note

Depends on nothing, but pairs with #618 — that PR fixes the bug that produced the wrong reason on the retry; this one makes whatever reason we have visible.