Add probe path selection for background liquidity probing

[151henry151]

Issue #2720 originally suggested a wrapper ScoreLookUp around ProbabilisticScorer. #3422 already added probing_diversity_penalty_msat for the same purpose; this PR wires that field into a dedicated path-selection API rather than adding a redundant wrapper.

Background prober loops (random target/amount on a timer) remain userland / separate-crate per maintainer consensus.

This adds RouteParameters::from_probe_target (uncapped routing fees for probing), ProbabilisticScoringFeeParameters::for_probing(amount_msat) (sets a diversity penalty when none is configured), a generic find_probe_route free function, a default Router::find_probe_route, DefaultRouter::find_probe_route_with_diversity for per-call dynamic diversity, and ChannelManager::send_probe_to_node as the simple find-and-send entry point. Preflight probe sending now shares an internal trim_unannounced_probe_last_hops helper; behavior is unchanged. Router and functional tests verify probe path diversity across repeated probes and end-to-end probe sending.

For ongoing probing with fixed amounts, configure diversity on the router at startup and use send_probe_to_node. For variable probe amounts, use DefaultRouter::find_probe_route_with_diversity and pass the first path to ChannelManager::send_probe, or use send_probe_to_node if trimming and sending in one step is enough. This is intentionally different from send_spontaneous_preflight_probes, which probes all MPP paths with payment fee caps and a liquidity multiplier for pre-payment training.

Fixes #2720

Tested with:
cargo +1.75.0 test -p lightning --lib probing — passed
cargo +1.75.0 test -p lightning --lib probes_for_diversity — passed
cargo +1.75.0 test -p lightning --lib preflight_probe — passed
cargo +1.75.0 test -p lightning --lib router — passed
cargo +1.75.0 doc -p lightning --no-deps — passed
RUSTFLAGS="--cfg=c_bindings" cargo +1.75.0 check -p lightning — passed
cargo +1.75.0 fmt --all — passed

[ldk-reviews-bot]

I've assigned @wpaulino 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]

All three of my prior comments have been addressed by the latest commit:

1. Doc bug (router.rs:2740-2744) — Fixed. The docs now correctly say to use send_probe for the returned route, with send_probe_to_node mentioned as a simpler alternative.
2. Divisor issue (scoring.rs:855-862) — Fixed. The code uses AMOUNT_PENALTY_DIVISOR and the comment accurately explains the derivation.
3. Shallow test (probing_tests.rs:28-30) — Fixed. The test now completes the full probe lifecycle with send_probe_along_route and expect_probe_successful_events.

I've reviewed all remaining code in the diff — the refactoring of trim logic, the Router trait extension, the Deref blanket impl, RouteParameters::from_probe_target, the free find_probe_route function, DefaultRouter::find_probe_route_with_diversity, send_probe_to_node, and all tests. No new issues found.

Review Summary

No new issues found. All three issues from the prior review pass have been addressed in the latest commit (cbd9c04 "Address review feedback on probing path selection"):

• lightning/src/routing/router.rs:2740-2744 — Doc bug (previously misleading send_probe_to_node guidance) is now fixed.
• lightning/src/routing/scoring.rs:855-862 — Divisor/comment issue is now correct, using AMOUNT_PENALTY_DIVISOR with an accurate explanation.
• lightning/src/ln/probing_tests.rs:28-32 — Test now completes the full probe lifecycle (forwarding + event verification).

[151henry151]

Addressed the bot feedback in cbd9c04: corrected the find_probe_route_with_diversity docs so pre-computed routes go through send_probe rather than send_probe_to_node, fixed the for_probing historical-amount divisor to AMOUNT_PENALTY_DIVISOR (the earlier 1 << 31 ignored the /2048 cancellation in combined_penalty_msat), and extended send_probe_to_node_happy_path to run the full probe lifecycle.

Is the norm here is to squash this kind of follow-up into one commit or keep the two-commit history?