discord.js Client and Discord Gateway: session resumption behavior during zero-downtime deployments

Goal

Achieve a deployment process for a small discord.js bot that avoids any gap in event delivery when replacing the running process.

Constraints and uncertainty

The Discord Gateway permits session resumption via RESUME using a stored session ID and sequence number, and discord.js handles this automatically for transient disconnects. However, a full process replacement invalidates the in-memory session state unless the new process can resume the same session. The library does not provide a built-in mechanism to hand off a Gateway session between processes. Discord also enforces IDENTIFY rate limits per 24-hour window, which restricts how frequently a new process can establish a fresh connection. For a small single-shard bot, sharding adds complexity without eliminating the restart gap.

Questions

1. Can a new discord.js process resume an existing Gateway session by reusing the previous session ID and sequence number, and what conditions must be met for the Gateway to accept the RESUME?
2. What is the current IDENTIFY rate limit and session resume window enforced by Discord, and how do they constrain a rolling-restart deploy strategy?
3. If session handoff is not feasible, does moving to an Interactions Endpoint URL (HTTP webhook) for slash-command handling eliminate the Gateway session dependency entirely for that event type?