feat: allow specifying a fee rate for channel-open funding transactions

[kaloudis]

Description

Zeus collects a sat/vB fee rate in its Open Channel flow, but on the LDK Node backend there is nowhere to send it: none of the open-channel APIs accept a fee rate, so every funding transaction goes out at whatever the internal estimator picks for ConfirmationTarget::ChannelFunding. This is the channel-open counterpart of the on-chain-send gap fixed by ZeusLN/zeus#4354, except here the parameter had to be added to the API itself.

All six open-channel entry points (open_channel, open_announced_channel, the _with_utxos and _fund_max variants) gain a trailing FeeRate? parameter, threaded exactly like the existing pending_funding_utxos mechanism:

• open_channel_inner stashes the rate in a new pending_funding_fee_rates: HashMap<u128, FeeRate> keyed by user_channel_id once create_channel succeeds
• the FundingGenerationReady handler removes it and passes it to Wallet::create_funding_transaction, which now takes Option<FeeRate> and falls back to the estimator when None (same pattern as send_to_address)
• when unset, behavior is byte-for-byte unchanged

Two deliberate extras:

• fund_max estimates at the override rate. estimate_max_funding_amount also takes the override; without this, the max amount would be computed at the estimator's rate, so a user-specified higher rate would produce a funding transaction that no longer fits (or a lower rate would undershoot capacity).
• ChannelClosed now clears all three pending maps (UTXOs, fund_max flags, fee rates). Previously, state stashed for a channel that was rejected by the peer or died before funding leaked forever; the new map would have inherited the same leak, and worse, a stale entry could apply an old fee rate to a later channel if the 128-bit user_channel_id ever collided.

Validation

• cargo check and cargo check --features uniffi pass
• cargo test --lib: 23 passed
• Kotlin and Swift bindings regenerate cleanly from the updated UDL (feeRate: FeeRate? appears on all six methods)
• cargo check --tests has 28 pre-existing errors on zeus from earlier arity changes (fixed on the rl-0.2.5-security-bump line by 02c62cb, not yet on zeus); this PR introduces no new ones, and its own test-call-site updates are included

Notes

• Stacks textually cleanly today, but Re-pin rust-lightning to zeus-0.2 (v0.2.5 + Zeus patches) #5 (rust-lightning 0.2.5 re-pin) touches the same files; whichever merges second needs a trivial rebase.
• Consumed by the Zeus-side threading PR (bridge + backends/LdkNode.ts), which is blocked on the next release tag from this repo.

[kaloudis]

Now also proposed upstream as lightningdevkit#1099 (adapted to current main: FundingAmount-era open_channel_inner, the _with_all/_0reserve variants, and the async funding handler). If upstream accepts it, this fork patch reduces to a rebase artifact the next time we re-sync; until then this PR is what the next Zeus release builds against.