feat(web): per-backend spend on the fleet rail

[saucam]

First buildable slice of P5.4 (§9, §7). The rail's cost figure now opens into a per-backend split — which backend is most of the bill, how many of its sessions are working, what it has spent.

§7 calls this a metaharness differentiator rather than a nicety, and the reason is structural: no single-vendor tool needs a per-backend breakdown, because it only ever has one backend.

Three decisions worth reviewing

The daemon's agg.totalCostUsd stays the headline number, not a sum of these rows. It counts tasks that may have aged off the capped client board, so a locally derived total would drift low exactly on the long-lived fleets where spend matters. This table answers a different question — how the spend splits — scoped to the sessions the board actually describes.

A session with no providerId is reported as unknown, never folded into the default backend. Attributing spend to a provider that may not have incurred it is worse than admitting the gap, in a view whose entire purpose is comparing backends against each other.

Share is zero when nothing has been spent — never an even split. Dividing by a zero total to show four backends at 25% would invent a fact from an absence.

Two smaller ones: sessions with no usage still count while contributing no spend (ten idle sessions read as ten sessions at $0, not an empty fleet), and active counts only genuinely in-flight turns — a session at waiting_approval is stopped and belongs in the attention queue, not the concurrency number.

Collapsed by default: it answers a question you ask occasionally; the lanes answer the one you ask constantly.

P5.4 triage — why this piece first

I checked the wire before picking. Of §12's five P5.4 items:

Buildable today (pure client):

• ✅ per-backend cost — this PR; providerId + SessionUsage are both on SessionInfo
• tree/map lens — lineage is derivable from role plus the task→session join
• event timeline — FleetEventWire carries type + createdAt

Blocked on daemon/protocol work:

• ❌ routing rationale + override ("↳ Opus · high-stakes edit") — no wire field carries why a backend was chosen
• ❌ cross-vendor review edges — the "reviewer gates worker" relationship isn't modelled anywhere
• ❌ rate-limit gauges (§9's reroute trigger) — no wire data at all
• ⚠️ full dispatch-timeline scrubber — FleetTaskWire has only createdAt, no updatedAt or transition history, so state transitions can't be reconstructed client-side. An event timeline is buildable; the scrubber §4 describes is not.

Happy to take the tree/map lens next, or to spec the protocol additions the blocked three would need.

Verification: 9 economics tests, 252 web tests total, typecheck / lint / build clean.

🤖 Generated with Claude Code

[highflame-oracle]

🔮 Oracle Review

🎯 Start Here

web/src/components/FleetRail.tsx (~20 min) — Security changes in FleetRail.tsx

---

📋 PR Summary

What this PR does: feat(web): per-backend spend on the fleet rail

---

🔍 Code Review

Review completed.

Review Stats:

---

Generated by Oracle - Highflame's AI Code Reviewer

[highflame-oracle]

🔮 Oracle Review

🎯 Start Here

web/src/lib/fleet-economics.ts (~21 min) — Security changes in fleet-economics.ts

---

📋 PR Summary

What this PR does: feat(web): per-backend spend on the fleet rail

---

🔍 Code Review

Review completed.

Review Stats:

---

Generated by Oracle - Highflame's AI Code Reviewer

[highflame-oracle]

Consider using Intl.NumberFormat for share percentages

While the current implementation returns a 0-1 ratio which is correct for the data layer, consider adding a helper for UI formatting that uses Intl.NumberFormat with percentage style. This would provide consistent localization (e.g., 25% vs 25,00%) across the application.

Suggested fix:

Suggested change

	}
	export function formatShare(share: number): string {
	return new Intl.NumberFormat(undefined, {
	style: 'percent',
	minimumFractionDigits: 1,
	maximumFractionDigits: 1,
	}).format(share);
	}