Throttle LSPS5 lifecycle cooldown resets

[tnull]

LSPS5 resets notification cooldowns when a peer reconnects so clients can receive prompt wake-ups after coming online. A peer can otherwise churn connections to clear the webhook cooldown repeatedly, turning the LSP into an amplification source for registered notification URLs.

Rate-limit how often peer lifecycle events may clear notification cooldowns while keeping the first reset immediate. Also make LSPSDateTime elapsed-time calculation directional so backwards clock movement does not make future timestamps look expired.

Co-Authored-By: HAL 9000

This finding was discovered by Project Loupe

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

Design consideration: the reset throttle (10s) is much shorter than NOTIFICATION_COOLDOWN_TIME (60s). Since each allowed reset clears last_notification_sent and lets a fresh notification through, an attacker churning connections can still force a webhook POST roughly every 10s instead of the 60s the cooldown otherwise enforces — i.e. ~6x amplification per registered URL remains possible. If the goal is to bound amplification to the cooldown, consider setting this interval to (or deriving it from) NOTIFICATION_COOLDOWN_TIME, or otherwise document why 10s is the intended floor.

[ldk-claude-review-bot]

I've re-reviewed the full diff and verified all duration_since call sites use the directional now.duration_since(&past) form (lsps5/service.rs:358, 620, 825, 841; lsps1/service.rs), so the directional change is safe. The throttle logic, TLV serialization, and both unit and integration tests trace correctly.

No new issues found beyond my prior review.

For reference, my previously posted findings still stand:

• lightning-liquidity/src/lsps5/service.rs:93 — Design consideration: the 10s reset throttle is much shorter than the 60s NOTIFICATION_COOLDOWN_TIME, leaving ~6x residual webhook-POST amplification per registered URL via reconnect churn.
• Cross-cutting: last_notification_cooldown_reset is non-persisted ((static_value, None)), dropping throttle state on restart — acceptable given the in-memory PeerState lifecycle, but it is security-relevant state.
• Cross-cutting: peer_disconnected also consumes the throttle budget with no client-facing benefit (peer is offline), but this is not a functional bug.

[TheBlueMatt]

Please word-wrap your commit messages.

[tnull]

Updated to line-wrap commit messages.