Reject unknown TLVs in blinded payment payloads

[officialasishkumar]

Fixes #4442.

Blinded payment payload decoding still applied the normal odd/even TLV handling, which let unexpected outer custom TLVs and unknown encrypted blinded TLVs slip through on blinded paths. This tightens both layers so blinded payloads now reject non-allowlisted TLVs instead of silently ignoring them.

The test updates keep the behavioral coverage aligned with the new decoding rules: the blinded payment flow now expects the recipient to reject custom TLVs on a blinded path, and the max-path-length tests stay focused on sender-side sizing logic.

Testing:

• cargo test -p lightning custom_tlvs_to_blinded_path
• cargo test -p lightning unknown_odd
• cargo test -p lightning one_hop_blinded_path_with_custom_tlv
• cargo test -p lightning blinded_path_with_custom_tlv

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

I've completed a thorough review of all files and hunks in this PR. Let me verify there are no issues I want to flag inline.

The changes are:

1. blinded_path/payment.rs: BlindedPaymentTlvs::read and BlindedTrampolineTlvs::read switched from _init_and_read_tlv_stream! to manual _init_tlv_field_var! + decode_tlv_stream_with_custom_tlv_decode! with a callback that skips padding (type 1), rejects unknown odd TLVs, and defers unknown even TLVs to the macro's default (which also rejects). Two unit tests added.

2. ln/msgs.rs: InboundOnionPayload::read and InboundTrampolinePayload::read now track unknown odd TLVs < 65536 via has_unknown_odd_tlvs flag, and check has_disallowed_blinded_tlvs (unknown odd + custom TLVs) for all blinded path variants (Forward, Dummy, Receive). One integration test added.

3. ln/blinded_payment_tests.rs: custom_tlvs_to_blinded_path test changed from expecting successful delivery to expecting rejection.

4. ln/max_payment_path_len_tests.rs: Tests simplified to only verify sender-side sizing logic, removing receiver-side delivery/claiming that would now fail.

I verified:

• The decode_tlv_stream_with_custom_tlv_decode! macro calls s.eat_remaining() after a callback returns Ok(true), so unread TLV bytes are properly consumed.
• The update_add_htlc.blinding_point is None for sender-originated payments (blinding point goes in onion TLV 12), so the error in custom_tlvs_to_blinded_path correctly produces a relay error (not malformed), matching the test assertions.
• All non-blinded paths remain unaffected — unknown odd TLVs are still silently skipped, custom TLVs still collected.
• The PaymentId changes in max_payment_path_len_tests are necessary because payments are no longer claimed between sends.

No issues found.

[TheBlueMatt]

thanks!

[TheBlueMatt]

nit you can drop this line (similar below), returning Ok(false) universally is fine.

[TheBlueMatt]

Please add a new macro for this rather than breaking it out.