Give CoinSelector its target instead of threading it through every call

[evanlinjin]

Why

A CoinSelector is built for one target and evaluated against it throughout — yet every method took the target as a parameter. Nothing stopped cs.excess(target_a, drain) being followed by cs.is_funded(target_b), and the metrics' correctness arguments (e.g. LowestFee::bound's proof that a changeless superset always costs more) are all stated at a fixed target, held together by convention rather than by types.

The crate had already reached this conclusion one layer down: BnbIter stored the target as a field, took it once in new, and re-passed it into metric.score/metric.bound at every node. This moves the binding up to where it belongs and deletes the re-threading.

It also unblocks follow-up work: with the selector knowing its target feerate, ancestor-aware CPFP pricing (#24) can be derived internally at the right rate instead of being validated at every call site. That branch is based on this one.

What

CoinSelector::new(candidates, target) owns the target; CoinSelector::target() exposes it for metrics that read it. Twenty signatures lose a parameter: fifteen public methods (excess, implied_fee, is_funded, drain, select_until_target_met, the four *_excess, …), bnb_solutions/run_bnb, and all three BnbMetric methods. Across the existing tests and benches, no selector was ever evaluated against more than one target — the per-call flexibility had no consumer.

Breaking changes

External BnbMetric implementations drop the target: Target parameter:

fn score(&mut self, cs: &CoinSelector<'_>) -> Option<Ordf32>;
fn bound(&mut self, cs: &CoinSelector<'_>) -> Option<Ordf32>;
fn drain(&mut self, cs: &CoinSelector<'_>) -> Drain;

Call sites move the target from each method call to CoinSelector::new. To evaluate a second target, build a second selector.

🤖 Generated with Claude Code