billing(ui): settlement-rail selection at checkout and switching in account settings, usage in compute-units

[JSONbored]

Context

Part of the dual-rail revenue epic. ⚠️ Blocked on #4930 (signup/checkout/plan-selector UI) — this issue extends that UI; do not start before it lands. Customers must be able to choose their settlement rail at checkout and switch later in account settings (#7665's surface), with usage always displayed in the one metered unit.

Requirements

1. Rail selection at checkout: a single explicit choice point (Bittensor rail vs conventional billing) inside Build a signup/checkout/plan-selector UI #4930's flow; everything upstream of the choice is rail-agnostic.
2. Rail switching in the account/billing surface (Spec: ongoing account-settings/billing-management UI (sibling to #4930's one-time checkout) #7665): switch takes effect at a defined boundary (decide and record: immediately vs next settlement period), never migrates or re-prices historical consumption, and is audited.
3. Usage display: normalized compute-units from the tenant-facing endpoint (Add tenant-facing AI-usage/cost endpoint (sumAiCostForTenantSince has zero real callers) — unit decided: normalized compute-units #7660) are the number shown everywhere; rail-native denominations appear only inside the rail-specific settlement detail, clearly labeled as settlement, not consumption.
4. Vocabulary isolation: the conventional-billing path contains zero crypto concepts (no wallet/stake/subnet language anywhere in its flow), and the Bittensor path presents its native affordances (wallet connect, stake source) without conventional-billing scaffolding — each audience gets a coherent, single-worldview flow. The isolation lives in the rail-selection boundary component, not scattered conditionals.
5. Every rail-facing action reflects settlement-backend state truthfully (pending/settled/failed from the interface's status, no optimistic "paid").

Deliverables

• The selection + switching UX and the usage display, integrated with Build a signup/checkout/plan-selector UI #4930/Spec: ongoing account-settings/billing-management UI (sibling to #4930's one-time checkout) #7665's surfaces, ui-kit components throughout.
• Tests: switch-boundary behavior, vocabulary-isolation checks (string-level assertions per flow), usage-figure source equality (UI figure === endpoint figure), settlement-status truthfulness states.

Expected outcome

A tradfi customer and a Bittensor-native customer each experience a coherent product; the rail is a checkout choice, not an identity.

[linear-code]

JSO-6361