Resolve odd startup / gunicorn refresh behavior

I observe that the health check will be successful for about 30-60 seconds before the RPC server is actually working.

It seems that RPC server is not actually ready to receive requests until after the first time it does a "refresh" and kills a worker!

This is what I'm talking about:

```
[2024-04-10T13:47:55.973+0000] {webserver_command.py:287} DEBUG - [1 / 1] Starting doing a refresh. Starting 1 workers.
[2024-04-10 13:47:55 +0000] [7] [INFO] Handling signal: ttin
[2024-04-10 13:47:55 +0000] [23] [INFO] Booting worker with pid: 23
[2024-04-10T13:47:57.079+0000] {webserver_command.py:249} DEBUG - [2 / 2] Killing 1 workers
[2024-04-10 13:47:57 +0000] [7] [INFO] Handling signal: ttou
[2024-04-10 13:47:57 +0000] [22] [INFO] Worker exiting (pid: 22)
[2024-04-10T13:47:57.080+0000] {settings.py:398} DEBUG - Disposing DB connection pool (PID 22)
```

Start with the startup and refresh flow in webserver_command.py, then inspect the database pool cleanup shown from settings.py. Reproduce the delayed readiness by checking the health endpoint before and after the first worker refresh. Done means the RPC server can receive requests when health checks first succeed, without relying on a refresh that kills a worker.

Written by the indexing model from the issue text.