Consider guarding against negative-effective-value foreign UTXOs in TxBuilder

**Describe the enhancement**

`TxBuilder::add_foreign_utxo` / `add_foreign_utxo_with_sequence` accept a foreign input without comparing its value to its spend cost at the builder's fee rate. Since manually added UTXOs are required, coin selection includes them even when their effective value is negative (`src/wallet/coin_selection.rs`, required output groups skip the `effective_value.is_positive()` filter that optional UTXOs go through). The deficit is then covered by the wallet's own inputs/change.

This is the intended "required means required" semantics for UTXOs the caller selects itself. But in collaborative flows (e.g. payjoin), the foreign input is nominated by a counterparty. A counterparty can supply an honestly described dust input (correct value, correct weight, `non_witness_utxo` present) and the local wallet ends up paying extra fee for it. The doc comment on `add_foreign_utxo` warns about a counterparty lying about value or weight, but not about truthful inputs whose effective value is negative.

Example: adding one 546 sat P2PKH foreign input to a 50,000 sat payment at 10 sat/vB raised the fee from ~1,405 to ~3,568 sat; net cost to the local wallet ≈ (spend cost − value) per such input.

This is likely a non-issue in practice, as a fee-reviewing application would notice the inflated fee, and payjoin receivers are expected to sanity-check contributed inputs anyway. Opening this to gather feedback from people building collaborative transaction flows on `bdk_wallet`: is it worth adding a guard/opt-in, or is a doc note sufficient?

Possible directions (leaving to maintainers' judgement):
- Reject or warn when a foreign input's effective value at the builder's fee rate is non-positive, with an explicit opt-in to allow it.
- Just extend the `add_foreign_utxo` doc comment to mention this case.

This issue was found by AI.

**Use case**

Payjoin / coinjoin style applications that add counterparty-provided inputs via `add_foreign_utxo`.

**Impact**
- [x] Nice-to-have / UX improvement

**Which backend(s) are relevant (if any)?**
- [x] None / not backend-related (e.g. `bdk_chain`, `bdk_core`)

Read src/wallet/coin_selection.rs and the add_foreign_utxo and add_foreign_utxo_with_sequence entry points, including the existing doc comment. Compare required and optional UTXO effective-value handling, then use the issue's guard, opt-in, and documentation options to frame feedback for maintainers. Done means a maintainer-selected behavior is agreed and its corresponding documentation or behavior is covered.

Written by the indexing model from the issue text.