fix(ai): keep per-provider failures when every chat route fails

[404oops]

TL;DR

When the chat fallback chain exhausts every provider, the alarm and log line read internal_error:All providers failed and nothing else, even though the driver already records each attempt's model, provider, status, code and message in the error's fields.attempts. This PR carries that detail into the alarm and adds one log line per exhausted chain, so an occurrence says which providers failed and how. 91 tests pass across the three touched suites; typecheck, ESLint and Prettier are clean on the source files.

Closes PUT-1615.

Why

The per-provider detail has existed since #3123, but it was dropped on the way to the operator:

• The alarm id and signature are built from legacyCode:message only, on purpose, so repeats dedupe into one incident.
• The first occurrence prints the error object, but Node's inspect stops at depth 2, so the log shows fields: { attempts: [ [Object], [Object] ] }.
• Repeat occurrences print only the message and a count. With dedup on, 33 of the 34 occurrences in the report were repeats, so nothing about their attempts was logged anywhere.
• Slack skips the error field in favour of the stack trace, which contains only the message.

What changed

• Alarm gate (src/backend/server.ts): an HttpError's fields are attached to the alarm under a single details key. One key cannot shadow the gate's own request fields, and because the alarm client merges fields on repeat, a repeat from a different thrower on a shared id (the forced 4xx codes are shared across drivers) replaces the previous details instead of leaving stale keys beside it. Slack, PagerDuty custom_details and the occurrence history all receive it.
• Chat driver (ChatCompletionDriver.ts): one console.warn per exhausted chain with the completion id, the resolved provider:model, the classified code and the attempts as JSON. The JSON console wrapper stamps the trace id on it, so every occurrence is greppable even when the alarm dedupes it. Chains the classifier marks noAlarm (a free model throttled upstream) do not log, for the same reason they do not alarm.
• Docs: the fields option on HttpError and doc/alarms.md now say that fields reaches both the client response body and the alarm, so it has to be safe to show the caller.

Verification

• vitest on server.test.ts, ChatCompletionDriver.test.ts, ChatCompletionDriver.edges.test.ts: 91 passed.
• New tests: the alarm gate boots a listening server with two routes. One throws an HttpError whose fields reuse the gate's own key names and asserts they land under details while the HTTP status and error object stay intact; the other throws a plain Error and asserts the same alarm id shape with no details. The driver test asserts the log line's prefix, route and serialized attempts; the existing free-model rate-limit test asserts no line is written.
• npm run typecheck: no new errors. ESLint and Prettier: clean on the changed source files. (doc/alarms.md fails Prettier on five pre-existing *italics* lines outside this diff; left alone.)

Not in this PR

• Slack truncates each field value at 400 characters, so a three-attempt chain may be cut there. PagerDuty and the log line carry the full list.
• attempts[].error is the raw upstream message and is unbounded; an SDK error embedding an HTML 502 page yields a large line. This predates the PR and also reaches the response body; capping it in toAttempt via the existing sanitizeUpstreamMessage would change what clients receive, so it deserves its own change.
• The classifier treats an attempt with no HTTP status and no timeout as our bug and pages critical, but connection resets and fetch failed errors land there too. Once this PR surfaces the attempts, most of the 34 reported occurrences will likely turn out to be that case. Reclassifying them is a separate alerting-behaviour change.

Reviewer callouts

• Alarm payload shape: every alarmed HttpError with fields now carries a details entry in Slack and PagerDuty. Nothing new reaches clients; fields was already serialized into the response body.
• No new endpoints, permissions, config keys or limits.

🤖 Generated with Claude Code

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	93.93% ⬆️ +0.01%	29546 / 31452
🔵	Statements	91.94% ⬆️ +0.01%	32104 / 34917
🔵	Functions	90.71% ⬇️ -0.16%	5394 / 5946
🔵	Branches	81% 🟰 ±0%	21375 / 26388

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
src/backend/server.ts	84.47% 🟰 ±0%	70.39% ⬆️ +1.59%	90.9% 🟰 ±0%	85.68% 🟰 ±0%	107-108, 122-127, 197-210, 237-245, 352, 360-363, 373-374, 414, 519, 525, 568-570, 604-605, 650, 660, 663, 703-708, 711-717, 720-726, 729-735, 762, 767, 771-773, 788, 808, 816-843, 861, 888-900, 903-910, 953, 984-989
src/backend/core/http/HttpError.ts	100% 🟰 ±0%	88.88% 🟰 ±0%	100% 🟰 ±0%	100% 🟰 ±0%
src/backend/drivers/ai-chat/ChatCompletionDriver.ts	96.49% ⬆️ +0.02%	89.88% ⬆️ +0.06%	97.56% 🟰 ±0%	97.75% ⬆️ +0.02%	216-219, 350, 380, 396, 460-462, 491-495, 530, 545, 578, 646, 788, 812, 818, 825, 1506

Generated in workflow #1753 for commit dcd89fc by the Vitest Coverage Report Action