Rate limit info now persists and streams across session reattach

What

• The rate-limit tracker gained a restoreLimits(limits, observed) method that directly reinstates a previously-known limit status and fires a status-changed event, bypassing the normal derive/observation pipeline.
• The "attach remote" flow now reads limit info (limits, limitsObserved, limitsEpoch) at session start, and on teardown re-applies it if it changed (or resets it if the epoch moved on); resumed sessions now also seed rate-limit info from prior state, alongside other already-seeded state.
• The CLI-facing query stream and the SDK/thin-client stream both now recognize a new rate_limit_event message type: they parse the rate_limit_info payload, strip out canUserPurchaseCredits/hasChargeableSavedPaymentMethod, and forward the rest into emitted events, logging a warning and dropping invalid payloads.
• Remote sessions gained adoption/settling machinery for these rate_limit_event frames: it seeds from prior rate-limit info, handles frames differently depending on whether they arrived via replay or live stream, and falls back to a default signal if catch-up truncates the history.

Why

This keeps your rate-limit status accurate and up to date across reconnects and session resumes, instead of losing that information when a session detaches and reattaches or streams through the SDK.