Report the sending peer in Event::OnionMessageIntercepted

[jkczyz]

When the OnionMessenger intercepts a message bound for an offline peer, it now reports which peer sent us the message to forward via a new prev_node_id field, so handlers can apply source-based policy when deciding whether to forward. The existing destination field is renamed peer_node_id -> next_node_id so the two node ids are unambiguous.

prev_node_id is None when the forward is enqueued by a message handler (the BOLT 12 static-invoice-server flow), which isn't given the sending node; otherwise it is the node we received the message from.

[ldk-reviews-bot]

👋 Thanks for assigning @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.

[ldk-claude-review-bot]

The previously flagged blocking issue at messenger.rs:1744 is now resolved — the offline-peer interception path correctly reports NextMessageHop::NodeId(next_node_id) instead of reusing next_hop verbatim. This is confirmed in the current commit.

I re-reviewed the full diff for new issues: the TLV serialization/compat logic (legacy field 0 peer_node_id, field 1 next_hop, field 3 prev_hop, read-side .or() fallback), the impl_ser_tlv_based_enum! macro on NextMessageHop, the new intercept_for_unknown_scids constructor arg threading, and the call sites (None on originate, Some(peer_node_id) on forward) are all correct.

No new issues found. The stale-comment minor issues at functional_tests.rs:1240-1242 and :1264 were already flagged in a prior pass and are not repeated here.

Cross-cutting note (previously raised, not re-flagged): enabling intercept_for_unknown_scids allows any unresolvable SCID to enqueue an event into the unbounded pending_intercepted_msgs_events, which lowers the bar for event-flooding versus the offline-peer path. This remains a design tradeoff the user explicitly opts into.

[TheBlueMatt]

thanks. hate changing the api at this point but backporting to 0.3 probably should happen cause its trivial

[ldk-reviews-bot]

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

[tnull]

Hmm, this seems to conflict with the first commit on #4463. Do you maybe want to pull that commit here to do it in one go?

[jkczyz]

Hmm, this seems to conflict with the first commit on #4463. Do you maybe want to pull that commit here to do it in one go?

Good idea! Done, but needed to rebase.

[TheBlueMatt]

two doc nits otherwise LGTM

[TheBlueMatt]

Does it make sense to just document it as "message is sent with a MessageSendInstructions::ForwardedMessage rather than forwarded internally in the OnionMessenger"?

[jkczyz]

Yeah, though gave an example of which method does that since it might not be apparent to users.