RStudio Connect load balancer and Shiny session lifecycle: can in-flight sessions survive a version redeploy?

We run a small Shiny application behind RStudio Connect's built-in load balancing and want to deploy new versions without kicking out users who are mid-session. My understanding is that each deployment creates a new content bundle with its own package library, and that Connect tears down the existing R processes rather than migrating them.

The uncertainty is at the boundary between the Connect scheduler and the Shiny runtime. Shiny's reactive state lives in R process memory, and I have not found a supported way to serialize reactive values, input bindings, or renderers across process boundaries. I also believe session$onSessionEnded only fires on clean client disconnects, not on server-initiated termination during a deploy, which would mean cleanup code never runs. Assume a recent Connect release (2023.09 or later).

Specific questions:

1. Does RStudio Connect expose any session-draining or graceful-shutdown hook before it stops an application's R processes during a redeploy?
2. Can the connectapi package (or the Server API) enumerate or signal individual active user sessions, or is teardown always unconditional?
3. If externalizing state (e.g., Redis via redux) is the only path, is there a documented reconnect flow so returning clients rebuild UI state against the new version?