Does Socket.IO connection state recovery survive a server restart, or do I need external persistence?

Goal

I want clients that briefly lose connectivity to receive the events they missed and keep their room memberships after reconnecting, even if the Socket.IO server process restarts during the outage.

Context and constraints

Assume Socket.IO v4.6+ on both server and client, with connectionStateRecovery enabled and a configured maxDisconnectionDuration. As documented, recovery state—session identity, rooms, and missed packets—is held in server memory by default. That implies a restart or crash inside the disconnection window discards it, and the reconnecting client is treated as brand new. In a multi-node setup I also understand room and recovery state is per node unless a compatible adapter (e.g., Redis) is configured, though I have not verified how that interacts with recovery specifically.

The documented alternative for durability is building at-least-once delivery myself using acknowledgements with timeouts (socket.timeout(ms).emit) plus client-side buffering or a custom event queue.

Questions

1. Is there any supported way to make connection state recovery itself survive a server restart, or is in-memory-only a hard design constraint?
2. Does configuring the Redis adapter change recovery durability across restarts or nodes, or does it only affect broadcast/room consistency?
3. If recovery cannot be made durable, what is the recommended way to combine it with acknowledgement-based retry so clients neither lose nor duplicate events?