feat(metrics): add ChangelessWaste for privacy-driven coin selection

[evanlinjin]

Summary

Adds a waste metric restricted to changeless selections, plus an internal cleanup of LowestFee::bound.

The new metric is for privacy-driven coin selection — CoinJoin / PayJoin / send-to-one-shot addresses where the change output is itself a leak. This matches the use case Bitcoin Core's BnB-CB algorithm covers. We deliberately don't expose a cross-regime Waste metric because optimising for waste tends to consolidate funds in ways most callers don't want (every input has negative waste contribution when long_term_feerate > feerate).

Public additions

• ChangelessWaste — minimise the waste metric subject to "no change output" per change_policy. Two-case bound:
  • rate_diff >= 0: lower-bound D.input_weight (resize trick when target not met, otherwise cs.input_weight).
  • rate_diff < 0: upper-bound D.input_weight via LP-relaxed knapsack on the candidates that must be excluded to keep excess below min_value.

Internal cleanup

Three private helpers in src/metrics.rs alongside the existing change_lower_bound:

• resize_bound — find-crossing-input + compute fractional scale. Shared by LowestFee::bound (target-not-met) and ChangelessWaste::bound.
• excess_with_drain — shortcut for "would-be excess if change materialised".
• lp_min_cost_to_cover — LP-relaxed fractional knapsack ("minimum cost of a fractional subset whose contributions sum to at least delta"). Shared by ChangelessWaste's rate_diff < 0 UB and LowestFee's "get rid of change" branch.

LowestFee::bound's "target met, has change, can we go changeless?" branch is also rewritten to use lp_min_cost_to_cover instead of a single-benchmark estimate. Provably ≥ the old bound (strictly tighter when amount_above_change_threshold > |ev_benchmark|); in the synthetic benches/lowest_fee_bounds pool the round counts come out identical (the divergence case doesn't fire on that pool shape), but the code is ~9 lines shorter and the named helper makes the intent clear. The old TODO: this metric could be tighter by being more complicated comment is removed.

Bound tightening for ChangelessWaste

The rate_diff < 0 (consolidation) case uses the LP-relaxed knapsack to bound D.input_weight. Round-count savings vs a trivial all_selected upper bound:

n	scenario	trivial	LP knapsack
20	rate_neg	34,296	2,138
30	rate_neg	2M (cap)	74,055

Why no general Waste metric?

Earlier iterations of this PR included a cross-regime Waste metric scoring both changeless and with-change selections via min(LB_changeless, LB_with_change). It was removed because:

• The metric over-consolidates: when long_term_feerate > feerate (a common low-fee scenario) every input has negative waste contribution, so the BnB optimum is "select every UTXO". Most callers do not want this.
• Bitcoin Core uses waste as a tiebreaker between solutions found by other algorithms (knapsack, SRD), never as the BnB objective. Same lesson here.
• The legitimate use cases — (a) tiebreaking equally-cheap fee solutions, (b) finding good changeless candidates — don't need the cross-regime bound. (a) can be done via tuple combinators with a non-waste primary; (b) is exactly ChangelessWaste.

Test plan

• cargo test --release — 26 tests pass (including ensure_bound_is_not_too_tight proptests on random pools for both ChangelessWaste and LowestFee).
• cargo clippy --all-targets — clean.
• cargo fmt --check — clean on every commit individually.
• cargo build — succeeds on every commit individually (verified on stable + MSRV 1.54.0).
• Manual review of ChangelessWaste::bound, the LP-knapsack helper, and the LowestFee::bound cleanup.

🤖 Generated with Claude Code