Pace collection startups and clarify deployment queue progress

README.md

@@ -86,8 +86,8 @@ may have accepted the request.
 Slots persist in SQLite across app restarts, and overlapping timer/API triggers
 share the active run. Beta options to skip health or match gates still work;
 skipping a beta gate does not release the fleet's recovery slot early. New-server
-creation is separate from deployment restarts and still starts its container
-directly.
+creation uses a separate shared startup queue, holding its slot through container,
+RCON, and selected-map verification.
 
 No token, no session, no auth freeze. If Komodo or RCON aren't configured,
 the sweep marks pending rows `manual` so nothing hangs forever.
@@ -114,6 +114,14 @@ shows target/existing/missing counts and IDs, ports, and key requirements for ne
 servers only. Already-satisfied targets create nothing; excess servers are kept.
 All jobs and capacity reservations are committed together before provisioning;
 one collection page tracks each server's independent progress and failures.
+New servers start one at a time by default across all collections and individual
+launches. A startup slot stays occupied until Komodo and RCON are healthy and
+RCON reports the selected map; an unready server holds the queue until it recovers
+or is removed. The queue survives application restarts. The collection preview
+shows the startup limit, and its progress page shows active startups and each
+server's place in the shared queue. Set `DEPLOYMENT_CREATE_CONCURRENCY` to a
+positive integer to increase the limit. Each worker pass starts at most the
+available number of slots; immediate failures do not drain the remaining queue.
 Existing single-server blueprints can be expanded with **Edit**. Single-server
 launches and launching again from recorded recipes remain available.
 Blueprints save maps and target lobby counts. Every new server uses the latest