SelectorParams mempool policy

[aagbotemi]

Description

Add a validated builder interface for SelectorParams that catches dust outputs, zero-value OP_RETURNs, oversized OP_RETURN aggregates, and non-standard script types at construction time. Pair it with a post-selection MempoolPolicy::check_all path for transaction-level standardness checks (weight, locktime, version, min-relay-fee, input spendability, witness stack limits, non-witness size).

Closes #41

Notes to the reviewers

• OP_RETURN policy choice. The v30 alignment question is discussed on #41. I implemented option 1 (100,000-byte aggregate cap matching Core v30 defaults).
• Two-layer split: SelectorParams::check_standardness runs output-side checks before coin selection. MempoolPolicy::check_all runs transaction-level checks after the Selection is built.
• Renamed change_dust_relay_feerate to dust_relay_feerate. The field applies to all outputs (target and change), not just change.

Changelog notice

• Added SelectorParamsBuilder with chainable setters and check_standardness validation
• Added MempoolPolicy with check_all and per-rule methods
• Renamed SelectorParams::change_dust_relay_feerate to dust_relay_feerate.

Checklists

• I followed the contribution guidelines
• I've added tests for the new feature
• I've added docs for the new feature
• I'm linking the issue being fixed by this PR

[noahjoeris]

I think the policy checks should be integrated more directly into the normal transaction-building flow.
Right now the caller has to remember to do a separate post-build check:

let policy = MempoolPolicy { tip_height, tip_mtp };
policy.check_all(&selection, &tx)?;

This is easy for callers to forget. It also asks them to provide both a Selection and a Transaction, even though the transaction should be derived from Selection + PsbtParams. A checked path should instead construct the transaction itself and validate exactly the transaction the crate is going to return.

Suggested shape:

• Output checks in SelectorParamsBuilder

  • build() could validate against a default policy.
  • build_with_policy(policy) could validate against a custom MempoolPolicy.
  • For unchecked, e.g. build_unchecked()

• Final transaction checks should happen in Selection.

  • create_psbt(...) defaults to e.g. Core v30
  • Add create_psbt_with_policy(policy) and create_psbt_unchecked()
  • This avoids a public check_all(&Selection, &Transaction) API and makes SelectionTxMismatch unnecessary

• So I think we should have some form of abstraction/config over policy.

  • No hardcoded policy values but make them part of MempoolPolicy struct.
  • Also chain-tip data is an unrelated runtime input that should be passed alongside, not embedded
  • Use MempoolPolicy::bitcoin_core_v30() as the default, for example.
  • Users should be able to pass a different policy if their node has different relay settings.
  • Then this policy can be passed into both SelectorParamsBuilder::build_with_policy(...) and Selection::create_psbt_with_policy(...).

Let me know what you think.