Expose pending HTLCs and channel dust exposure

[tnull]

Make pending payment state and dust exposure available to callers so they can inspect stalled payments and assess force-close risk. Also expose the maximum splice-out amount to help plan withdrawals.

Expose the same information through Rust and the language bindings.

Rust and UniFFI checks, unit tests, the new integration test in both configurations, doctests, and binding generation pass. The full integration run had two failures in existing tests. Both passed in isolation, but channel_full_cycle_force_close_trusted_no_reserve failed again with Bitcoin Core RPC at tests/common/mod.rs:632. Its clean-main run passed, so the cause remains unresolved. UniFFI rustdoc also fails on three broken links reproduced on main.

Fixes #1102

[ldk-reviews-bot]

I've assigned @TheBlueMatt 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.

[f3r10]

Thanks, this looks good to me overall, and the test covering a dust and a non-dust HTLC at the same time is nice.

And about that comment on the commit: I ran channel_full_cycle_force_close_trusted_no_reserve 5× on this branch (4 pass, 1 fail [panic: …]) and 5× on the parent commit (5 pass). That's too few runs to tell whether the test is flaky or something changed here, but since this diff only adds read-only fields to ChannelDetails and nothing in the force-close path touches them, I'd expect a pre-existing flake.

[tnull]

And about that comment on the commit: I ran channel_full_cycle_force_close_trusted_no_reserve 5× on this branch (4 pass, 1 fail [panic: …]) and 5× on the parent commit (5 pass). That's too few runs to tell whether the test is flaky or something changed here, but since this diff only adds read-only fields to ChannelDetails and nothing in the force-close path touches them, I'd expect a pre-existing flake.

Yeah, it's flaky currently.