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 async_payments_tests.rs usages all use the .. pattern and the peer_node_id locals there are unrelated variables. Consistent with my prior review.

No issues found.

This is a re-review of the same commit (41ef2e6). My prior analysis holds: the field rename plus addition is clean — TLV field 0 remains the destination peer (backward/forward compatible), field 1 is the new optional prev_node_id, both call sites are updated consistently with the documented semantics, and all remaining match arms either were updated or use ... No new bugs, security problems, or logic errors detected.

[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?