Wire the dig-sex reward ledger (SPEC 2A) -- record and persist; claim mechanism still blocked

[MichaelTaylor3d]

Task

dig_sex::reward -- RewardLedger, record, claimed_for, reconcile_from_chain, RecordOutcome -- is implemented, tested and unused.

Wire the ledger half now: persist it on disk per store, record claims idempotently, and make claimed_for answerable.

What is deliberately NOT in scope

The claim mechanism -- how the node actually claims rewards from an on-chain distributor. The user has said those details are coming later. Do not invent them, and do not build a speculative claim path that will have to be torn out.

This is done when the ledger is real, persistent and correct, so the claim path has somewhere to record into once it is specified.

Why the constraints matter

• Chain is authoritative. reconcile_from_chain exists so on-chain truth overwrites local belief, never the reverse.
• Recording is idempotent. Replaying a chain event must not inflate the total. The crate already carries a revert-proof for this (replaying_a_chain_event_cannot_inflate_the_total); the persistence layer must not undo the property by, for example, keying rows on insertion order rather than the claim id.
• It fails toward UNDER-counting. If the ledger is unsure it reports less claimed, never more. Over-reporting claimed rewards is a surface that lies about money.

Context

• Persistence belongs with node state under the per-user AppData location, sealed at rest to the user key alongside the rest of node state (NC-2 / NC-3).
• dig-sex SPEC.md section 2A.

Evidence

A test that fails without the fix: record a claim, restart, assert claimed_for still returns it; then replay the same claim and assert the total is unchanged.

Parent

Orchestrator epic: https://github.com/DIG-Network/dig_ecosystem/issues/3138

[MichaelTaylor3d]

Lane loop/batch-digsex (worktree dn-digsex) owns this. Draft PR #456, branch loop/batch-digsex.

Measured before starting: dig-sex latest published is 0.5.0 (not 0.4 as the sibling ticket says), and dig-node already declares dig-sex = "0.5" at crates/dig-node-core/Cargo.toml:509. dig_sex::conduct, dig_sex::admission and dig_sex::reward have zero references anywhere in crates/ — so these three are genuinely unwired, as filed.

[MichaelTaylor3d]

NOT STARTED — deliberately deferred, with the blocker measured

This lane shipped #268 and #269 (the two with a security dimension, per the batch brief's split) and verified #287 + #270 as already-shipped. #271 was not started, and I am reporting that rather than half-wiring it.

Confirmed still genuinely unwired: dig_sex::reward has zero references anywhere in crates/ — RewardLedger, record, claimed_for, reconcile_from_chain and RecordOutcome are all unused, exactly as filed. The crate side is present in dig-sex 0.5.0 (src/reward.rs, 246 lines, all five items re-exported at the crate root).

Why I stopped rather than continuing. The ticket requires persistence "under the per-user AppData location, sealed at rest to the user key alongside the rest of node state (NC-2 / NC-3)". I could not find an existing sealed-at-rest node-state helper to reuse: crates/dig-node-core/src/chat.rs seals messages to a recipient key (seal_outbound, a different composition and a different key), and I found no general state-sealing routine. So the sealing layer is new work with a key_mgmt dependency I have not measured.

Writing the ledger as plaintext JSON under the cache dir would have compiled, passed a round-trip test, and violated the ticket's own NC-2/NC-3 constraint on a money-adjacent record. That is the wrong direction to guess in, so it is left for a lane that can settle the sealing shape first.

What a follow-up lane should know before starting:

• The idempotency property the ticket protects is already proven crate-side (replaying_a_chain_event_cannot_inflate_the_total). The risk is entirely in the persistence layer undoing it — key the rows on ClaimId, never on insertion order.
• RewardLedger::from_chain_claims and reconcile_from_chain exist precisely so chain overwrites local belief and never the reverse.
• Node::cache_dir_path() is the obvious location anchor, but the sealing question sits above it and should be decided first.
• Claim mechanism stays out of scope, as filed.

Leaving open and unclaimed.