Fix Borrow/Hash inconsistency on Payment* types

[TheBlueMatt]

Borrow'd values are required to Hash identically to the original object so that a Borrowed key can be used in place of an owned one in a HashMap lookup.

We'd violated this on our Payment* types, which we fix here. Note that changing the Hash implementation is generally not considered an API-breaking change and this seems like a useful fix.

Reported by Project Loupe.

[ldk-reviews-bot]

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

No issues found.

All manual Hash impls correctly hash via self.borrow() (the &[u8] slice path), guaranteeing consistency with the Borrow<[u8]> contract; Eq is unchanged and remains consistent; and the CryptoHash rename correctly disambiguates bitcoin::hashes::Hash from core::hash::Hash.

This version of the PR resolves my prior cross-cutting concern: PaymentId (channelmanager.rs:649), InterceptId (channelmanager.rs:699), and ChannelId (types.rs:122) now all receive manual Hash impls too. OfferId (offers/offer.rs:122) has Borrow<[u8]> but does not derive Hash, so it is correctly unaffected.

The claim_payment_internal change to payment_preimage.into() is behaviorally equivalent to the previous explicit SHA256 hashing (via the From<PaymentPreimage> for PaymentHash impl) and is a reasonable de-duplication.

No inline comments posted — the changed lines are correct and the previously-flagged sibling types are now fixed.

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

[TheBlueMatt]

Skipping backport because this isn't actually a bug, even if the code is super sketch - rust-bitcoin/rust-bitcoin#6365