dig-wallet: select_xch is a fourth largest-first rival and disagrees with its three siblings on overflow direction

[MichaelTaylor3d]

Task

There are now FOUR largest-first coin selectors in this repo, and the extraction of the canonical one
made the divergence between them ASYMMETRIC rather than merely duplicated. select_xch is the odd
one out and it differs in overflow direction, which is a behaviour difference on a money path,
not a style difference.

Context

The four:

#	symbol	overflow on the running total
1	crates/dig-wallet/src/sage/selection.rs:57 select_largest_first	the canonical one, the extraction
2	crates/dig-wallet/src/sage/offers.rs:438 select_cats
3	crates/dig-wallet/src/sage/rpc.rs:4814 select_cat_rows
4	crates/dig-wallet/src/sage/offers.rs:412-429 select_xch	sum += c.amount — plain +=

select_xch:420 accumulates with a bare +=. In a debug build that PANICS on overflow; in a release
build it WRAPS, and a wrapped sum can satisfy the sum >= need break, returning a coin set whose
real total is far below need. The consumer of mirror::funding (dig-node#421,
funding.rs:204-206) uses saturating_add on the same running total and refuses on shortfall
instead.

Two different wrong answers for the same input is worse than two identical implementations:
duplication costs maintenance, disagreement means one of them is wrong, and the one that ships in
release mode is the one that wraps.

Scope

Per CLAUDE.md §2.0's centralize-rival-implementations rule, the finding is the DISAGREEMENT and the
survivor must be NAMED. select_largest_first (#1) is the canonical home; the expected outcome is
that #4 — and, on inspection, #2 and #3 — call it and are DELETED, rather than being individually
corrected into agreement, which produces a fourth agreeing rival.

Before deleting: check whether each caller's tie-break and its failure type are genuinely the
canonical one's. select_xch sorts b.amount.cmp(&a.amount).then(a.coin_id().cmp(&b.coin_id())),
which looks like the canonical key but must be confirmed rather than assumed.

A regression test must exist for the wrap specifically — a fixture whose amounts sum past u64::MAX
— or the fix is unproven in the build that has the defect.

Evidence

Raised by the pre-merge security gate on dig-node#423 as a non-gating follow-up. Not absorbed into
that PR, whose re-gate scope was the reservation defect.

Parent: #421

[MichaelTaylor3d]

Correction — this ticket's premise is wrong, and the true defect is bigger and differently shaped

I filed this as "select_xch is a fourth largest-first rival and disagrees with its three
siblings on overflow direction." Measured on main, there is no disagreement. All four do a
bare sum += c.amount on u64 and wrap identically:

site	overflow
crates/dig-wallet/src/sage/spend.rs:468 select_coins	bare +=, wraps in release
crates/dig-wallet/src/sage/rpc.rs:4731 select_cat_rows	bare +=, wraps
crates/dig-wallet/src/sage/offers.rs:412 select_xch	bare +=, wraps
crates/dig-wallet/src/sage/offers.rs:433 select_cats	bare +=, wraps

So this is one shared defect at four sites, not one site diverging from three correct ones. The
correct behaviour is checked or saturating accumulation and none of the four shipped it. Failure
direction: a wrapped sum can satisfy sum >= need, producing a bundle built on coins that do not
cover the amount — an underfunded spend presented as funded. Unreachable for XCH, whose total
supply is below u64::MAX; reachable for a CAT with a large tail supply, or wherever the rows are
attacker-supplied.

The real disagreement is elsewhere, and it is on the $DIG path

select_cat_rows alone parses a STRING amount, with .parse::<u64>().unwrap_or(0). An
unparseable amount silently becomes zero, so the coin is pushed into the selection while
contributing nothing. Two ways that surfaces, both wrong about money:

• the wallet is charged a coin spend for zero value, and the spend under-funds; or
• it reports insufficient CAT balance on a wallet that holds the funds.

select_coins takes a typed u64 and cannot do this. The wrong one shipped, and it is the $DIG
CAT path — the same path epic https://github.com/DIG-Network/dig_ecosystem/issues/410 exists to
unblock.

Where this should be fixed

Fold this into https://github.com/DIG-Network/dig_ecosystem/issues/418 — same repo, same file
set, same four functions. #418's scope is adopting dig-l1-wallet v0.3.0's capped descending
selector with a NeedsConsolidation signal distinct from InsufficientFunds, and all four rivals
are deleted in that adoption. Fixing the accumulator separately means touching the four functions
twice.

Done condition for the combined work: no bare largest-first accumulator remains in
crates/dig-wallet/src/sage/, and a test proves NeedsConsolidation is distinct from
InsufficientFunds.

Also worth knowing before that PR

dig-node PR #423 introduces sage::selection::select_largest_first — a fifth rival in the repo
this work removes them from. Not blocking #423, which is on the epic #3166 critical path, but the
adoption should consume the shipped crate rather than inherit another local extraction.

The measurement stands even though my framing did not; I was reporting a difference I had inferred
from three function names rather than read from four function bodies.