Socket.IO connection state recovery across server restarts: what actually persists?

I'm designing a repeatable development setup for a Socket.IO application (Node.js, socket.io 4.x) and trying to pin down the exact limits of connection state recovery before committing to an architecture.

My understanding is that connectionStateRecovery is enabled by default and lets a client resume its session within maxDisconnectionDuration (default two minutes), replaying missed packets. But this appears to depend on the same server process still holding the session state. In a containerized dev environment where processes restart frequently, or a multi-node setup behind a load balancer, recovery seems to silently fall back to a brand-new session with a new socket.id.

The documented options seem to be the Redis adapter (or Redis streams adapter) for cross-node broadcast, plus sticky sessions unless I force WebSocket-only transport. What I can't resolve is whether any supported configuration actually preserves session recovery across a full server restart or node migration, or whether recovery is strictly an in-process, brief-disconnect feature.

Specifically:

• Does @socket.io/redis-streams-adapter extend connection state recovery so a client can resume its session on a different node or after a restart, or does it only solve broadcast fan-out?
• If recovery silently fails and the client gets a fresh session, is there a documented server-side signal to distinguish "recovered" from "new" so application state can be rebuilt deterministically?
• Is forcing WebSocket-only transport the accepted way to drop the sticky-session requirement in a repeatable dev environment, and what fallback do I lose?