Preserve the granted subscription lifetime after sign-in refresh #33

An explicit subscription created near sign-in expiry can renew for longer than its original grant after the sign-in is refreshed.

In McpEvents.subscribe, expiresAt is capped at the current sign-in expiry, but renewalTtlMs stores the requested TTL after applying the server limits. McpEventDeliveries.acknowledge later adds that stored TTL and caps it at the sign-in's current expiry. Refreshing the sign-in between those operations exposes the mismatch.

Example: request seven days while the sign-in has one hour remaining. The returned grant lasts one hour. Refresh the sign-in, then acknowledge a delivery before that hour expires. The subscription can then receive seven days from acknowledgement instead of its originally granted one hour.

Preserve the granted lifetime by storing expiresAt - now when the subscription is created or explicitly refreshed. Keep the notify-only zero-renewal behavior, client renew calls, and secret rotation intact. Add a focused case to the existing McpEvents tests that caps the original grant, refreshes the sign-in, acknowledges a delivery, and asserts renewal uses the original grant duration.

P2 follow-up from PR #25, reviewed commit 6443f743006d209cd4daac28608415aed48ab848. The current renewal remains capped at the live sign-in expiry. Chris's round-two policy tracks P2 findings as issues; this does not hold the initial renewal release.

Original finding: #25 (comment)