Expose channel reserve in open channel requests

[DeepCogNeural]

Fixes #3909.

This exposes the channel reserve in Event::OpenChannelRequest::params by adding channel_reserve_satoshis to msgs::ChannelParameters.

• For V1 requests, the value comes from the peer's open_channel.channel_reserve_satoshis.
• For V2 requests, the value is derived through the existing V2 reserve helper, including disable_channel_reserve.
• Keeps the reserve-specific construction internal so CommonOpenChannelFields alone does not have to manufacture a full ChannelParameters.

Validation run locally:

• rustfmt +1.75.0 --check --edition 2021 lightning/src/ln/msgs.rs lightning/src/ln/channelmanager.rs lightning/src/ln/channel_open_tests.rs
• cargo test -p lightning test_open_channel_request_exposes_v2_channel_reserve
• cargo test -p lightning test_inbound_anchors_manual_acceptance
• cargo check -p lightning
• git diff --check

Note: cargo fmt --check and cargo clippy -p lightning --tests -- -D warnings currently report pre-existing formatting/lint output in unrelated files such as lightning/src/ln/channel.rs and lightning-macros/src/lib.rs; this PR does not touch those files.

[ldk-reviews-bot]

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

For V2 dual-funded channels the reserve is computed from only the peer's funding_satoshis, but the reserve actually enforced on the holder is derived at accept time from the total channel value (our_funding_contribution + msg.funding_satoshis, see InboundV2Channel::new). If the acceptor contributes funds (as is the whole point of dual funding), the value exposed here will be lower than the reserve that ultimately applies. At event time the acceptor's contribution isn't known yet, so this can't be fully accurate — but worth documenting on the field/changelog that for V2 this reflects only the initiator's contribution, otherwise consumers may rely on a value that doesn't match the final reserve.

[ldk-claude-review-bot]

I've re-reviewed the full PR against my prior findings. Verified:

• V1: exposed channel_reserve_satoshis = msg.channel_reserve_satoshis, which matches the enforced counterparty_selected_channel_reserve_satoshis (channel.rs:4130). Direction correct.
• V2: exposed value uses get_v2_channel_reserve_satoshis(funding_satoshis, MIN_CHAN_DUST_LIMIT_SATOSHIS, disable), matching InboundV2Channel::new (channel.rs:15710). Since acceptor contribution is currently hardcoded to 0 (dual-funding TODO), the value currently matches exactly.
• ChannelParameters is only constructed at msgs.rs:242, so the new field causes no other compile breakage.
• The new commit "Document V2 channel reserve exposure timing" added field/changelog documentation, which resolves my prior comment about the V2 acceptor-contribution timing gap.

No new issues found.

Prior concerns status:

• channelmanager.rs:1924 (V2 reserve reflects only initiator's contribution) — now resolved by the added doc comment on ChannelParameters::channel_reserve_satoshis and the changelog note.
• Behavior change: V2 dust-limit validation now happens at open time as send_err_msg_no_close rather than at accept time — still stands as a non-blocking note (fail-fast, and send_err_msg_no_close is appropriate since no channel exists yet).

No additional bugs, security issues, or compilation breakage identified in this pass.