Epic: dual-rail revenue — one metered unit, two settlement rails (Bittensor + conventional billing)

[JSONbored]

Context

LoopOver's hosted product must generate real revenue on two settlement rails from one metered product: on-chain (Bittensor — stake→compute-time pricing #4790, the external-subnet credit-bridge #6569, and Wave 5.1's subnet-funded reward pools #6101) and conventional (billing SDK #4919, quota/plan/invoice model #4920, payment integration #4803, signup/checkout #4930, account/billing UI #7665, rate card #4804). The architectural seam for this already exists and is decided: the pluggable settlement-backend interface (#6098, closed/designed) with rental-ledger consumption entries (#6314) and normalized compute-units as the metered unit (decided on #7660).

What does not exist: anything that forces the two rails to stay behaviorally equivalent, anything that lets a customer choose and switch rails, and any uniform internal view of revenue across both. Without those, the rails will drift into two de-facto products. This epic is the umbrella that keeps "same loop, whichever rail you pay on" true in code, UX, and reporting.

Scope groups (native sub-issues)

1. Settlement-rail conformance harness — a shared test suite both rail adapters must pass against Design spec: settlement-backend interface (gittensor-owned or self-built, pluggable either way) #6098's interface.
2. Rail selection UX — choose at checkout, switch in account settings, usage shown in normalized compute-units.
3. Cross-rail revenue reporting — one internal operator view of consumption and settlement across both rails.

Hard constraints

• One metered unit. Normalized compute-units are the only consumption currency; rails convert at settlement, never at metering.
• No pricing content here. Amounts, margins, and the rate card are Pricing model & rate card #4804's scope and stay out of this epic and its children.
• Nothing rail-specific leaks upward: product surfaces above the settlement interface must not branch on rail except in the explicit selection component.

Expected outcome

A customer on either rail consumes the identical product, sees identical usage, and can switch rails without migration; internally, one report answers "what did the loop earn this week" across both.

References

Builds on #6098 (interface, decided). Relates to #6314, #7660, #4790, #6569, #6101, #4919, #4920, #4803, #4930, #7665, #4804, #4791.

[linear-code]

JSO-6345