settlement: rail conformance suite — any adapter of the #6098 interface must pass the identical scenario set

[JSONbored]

Context

Part of the dual-rail revenue epic. The settlement-backend interface is designed (#6098, closed) and consumption flows through rental-ledger entries (#6314) in normalized compute-units (#7660's decided unit). Two rails will implement that interface — Bittensor-side (stake→compute-time #4790, credit-bridge #6569, Wave 5.1 pools) and conventional billing (#4919/#4920/#4803). Nothing currently forces the rails to remain behaviorally equivalent; without a conformance harness they will drift into two de-facto products with rail-specific bugs.

Requirements

1. A shared conformance suite parameterized over implementations of the Design spec: settlement-backend interface (gittensor-owned or self-built, pluggable either way) #6098 interface: any rail adapter (and the reference/test double) runs the identical scenario set.
2. Scenario coverage, at minimum: identical consumption stream → equivalent settlement outcome (net of rail-native units); idempotency under retried settlement calls; partial-failure recovery (settlement interrupted mid-batch resumes without double-charge); refund-path parity per Settlement & refund handling #4791's semantics; zero-consumption and cap-boundary periods; ledger-entry immutability (settlement never mutates consumption history).
3. Both sides of every branch: each scenario asserts the success arm and the defined failure arm (declined/insufficient-funds/unreachable-rail), with the failure taxonomy shared across rails — a rail may map, but not invent, failure categories.
4. The suite is wired into test:ci so a rail adapter cannot merge without passing it; adding a third rail later means implementing the interface and passing this suite, nothing more.
5. No amounts/pricing in scenarios beyond arbitrary test constants — pricing is Pricing model & rate card #4804's scope.

Deliverables

• The conformance suite + a reference in-memory adapter proving the suite runs green pre-rails.
• CI wiring; a short doc section stating the "any new rail must pass this" contract.

Expected outcome

"Same loop, whichever rail you pay on" is enforced by tests, not intentions — settlement behavior is provably rail-independent.

[linear-code]

JSO-6360