Persist rental-ledger consumption entries against the settlement-backend interface

[JSONbored]

Problem: #4792 shipped buildLoopConsumptionEntry/totalConsumptionForTenant (packages/loopover-engine/src/loop-consumption.ts) as a pure decision core with deliberately no storage opinion — persisting entries was explicitly deferred as "the separate, blocked-on-#4789/#4790 integration." That integration was never filed as its own issue; it only existed as a sentence inside #4792's body, so there's nothing a contributor or maintainer can pick up once #4789/#4790 clear.

Area: Platform / gittensor economics — rental ledger

Proposal: Wire buildLoopConsumptionEntry's output into a real settlement backend via #6098's SettlementBackend interface (recordPayout/getPoolBalance) — call recordPayout with a PayoutEligibleEvent on every completed or killed loop run, per #6098's already-resolved contract. No new persistence design needed; #6098 already specifies the shape.

Deliverables:

• Real persistence of LoopConsumptionEntry rows via SettlementBackend.recordPayout, wired into the loop-completion path.
• Idempotency verified: a retried delivery of the same run's completion must not double-call recordPayout (per Design spec: settlement-backend interface (gittensor-owned or self-built, pluggable either way) #6098's own idempotency requirement).

Acceptance criteria:

• A completed test loop's consumption entry results in exactly one recordPayout call, reconcilable against the tenant's pool balance.
• A retried/duplicate completion event does not double-decrement the pool.

Resources:

• packages/loopover-engine/src/loop-consumption.ts (Rental ledger integration #4792, the pure core this wires up)
• Design spec: settlement-backend interface (gittensor-owned or self-built, pluggable either way) #6098 (settlement-backend interface — the contract this implements)
• Replace the local-file database abstraction with a shared datastore for hosted use #4940 (storage abstraction — whatever backend this integration ultimately persists through)

Boundaries:

• Blocked on Neuron/hotkey registration flow #4789 (registration) and Stake/payment → compute-time pricing #4790 (pricing), per Rental ledger integration #4792's own original scope boundary.
• Does not choose or implement a SettlementBackend itself (gittensor-owned vs. self-built) — that's a separate decision Design spec: settlement-backend interface (gittensor-owned or self-built, pluggable either way) #6098 deliberately stayed agnostic to.
• No pricing/reward-formula numbers, wallet, or hotkey material.

---

Part of #4778.

[linear-code]

JSO-4410

[JSONbored]

Label correction (2026-07-16): removed `gittensor:feature`, added `roadmap` — this persists real payout/ledger entries against a settlement backend, the same financial-critical class as #4790. `roadmap`+`maintainer-only` is the correct pairing. Readiness is expressed by the real `blockedBy` links on #4789/#4790, not by label ambiguity.