The client now suggests a subscription lifetime via ttlMs on
events/subscribe; the server's refreshBefore grant is authoritative and
SHOULD only shorten (clamping up to a server minimum TTL is the one
sanctioned exception). An explicit ttlMs: null requests no expiry, and
refreshBefore: null grants it.
This reframes server-side durability as the server's choice, coupled to
the TTLs it grants: short grants keep the existing in-memory soft-state
model, while long or no-expiry grants shift durability and cleanup onto
the server (persist across restarts, persist verification status,
failure-based GC instead of TTL expiry, no expectation of unsubscribe).
Rationale: long-lived tenants with many subscriptions shouldn't be
forced into a server-invented refresh cadence, and a one-year TTL is
practically unlimited anyway — better to offer no expiry explicitly and
attach the real obligations to it.
99f3589c83