Add a payment_metadata map in blinded * path contexts

[TheBlueMatt]

Similar to how BOLT 11 payments can use a `payment_metadata` to
provide arbitrary bytes in the invoice to be communicated back to
them when receiving, its useful to be able to provide some bytes
which are communicated back upon receiving a payment.

Here we do so in the BOLT 12 blinded * contexts, offering a
`BTreeMap<u64, Vec<u8>>` instead to enable more easily including
multiple sets of data.

Also note that a `Router` building a blinded path is allowed to
modify the `payment_metadata` without breaking the payment.

Tests by claude

We do so both in the blinded message and payment paths, supporting async payments when data is injected in the blinded payment paths (eg via the Router). We don't expose building offers with metadata yet.

[ldk-reviews-bot]

👋 Thanks for assigning @tnull 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 the necessary Writeable impls for reference types are in place. The review is complete.

No issues found. All previously flagged issues have been addressed (typos fixed, doc reference verified correct). The implementation is correct: TLV backwards compatibility is maintained with odd type numbers, serialization macros work properly with reference types, metadata flows correctly through all paths, and pattern matches are exhaustive.

No issues found.

All previously flagged items from prior review passes have been resolved:

• "tightly" typo: fixed in current code
• OffersContext::StaticInvoiceRequested::payment_metadata doc reference: was a misread; the doc at messenger.rs:474 actually references OffersContext::InvoiceRequest::payment_metadata which exists

Verification completed across all 15 changed files covering: TLV serialization correctness (odd type numbers, ascending order), macro (option, encoding) pattern with .as_ref(), BigSizeKeyedMap DoS safety (bounded reads, no pre-allocation, duplicate key rejection), metadata propagation through all code paths (offer message path -> channelmanager extraction -> invoice builder -> payment context -> blinded payment path -> Event::PaymentClaimable), pattern match exhaustiveness, and backwards compatibility for old readers.

[codecov]

Codecov Report

❌ Patch coverage is 85.26316% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.16%. Comparing base (42e198c) to head (98cff64).

Files with missing lines	Patch %	Lines
lightning/src/util/ser.rs	74.07%	1 Missing and 6 partials ⚠️
lightning/src/blinded_path/payment.rs	71.42%	6 Missing ⚠️
lightning/src/util/test_utils.rs	91.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4584      +/-   ##
==========================================
+ Coverage   87.15%   87.16%   +0.01%     
==========================================
  Files         161      161              
  Lines      109251   109329      +78     
  Branches   109251   109329      +78     
==========================================
+ Hits        95215    95296      +81     
+ Misses      11560    11549      -11     
- Partials     2476     2484       +8     

Flag	Coverage Δ
fuzzing-fake-hashes	31.18% <16.25%> (+0.03%)	⬆️
fuzzing-real-hashes	22.90% <1.25%> (-0.02%)	⬇️
tests	86.23% <85.26%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.