Pace collection startups and clarify deployment queue progress

docs/deployment-blueprints.md

@@ -28,7 +28,7 @@ destroy servers or change existing servers' files.
 3. Choose **Save & preview** to review every new server ID and game port.
 4. Enter each lobby's Plutonium key, or leave its field blank to reuse the key
    saved for that exact server ID.
-5. Choose **Create N missing servers** and follow their collection progress page.
+5. Choose **Queue N servers** and follow their collection progress page.
    If every target is already met, choose **Done**; no operation is created.
 
 Blueprints support up to 40 distinct game/map selections, 1–20 lobbies per map,
@@ -58,11 +58,24 @@ capacity changes before submission, the request is rejected without changes and
 requires a fresh preview. Previously saved additive previews are checked against
 the current shortfall too.
 
-The worker provisions servers sequentially; health verification and failures are
-recorded separately for each. One failure does not undo servers already created
-or prevent the rest of the queued collection from being attempted. The collection
-page summarizes verified, active, and failed operations and links to every
-server's timeline and recovery options. Each child links back to its collection.
+All collections and individual launches share one startup queue, ordered by request
+time. By default, one server starts at a time. Its startup slot remains occupied
+until Komodo is healthy, RCON answers, and the reported map matches the selection.
+Only then can the next queued server start. Set `DEPLOYMENT_CREATE_CONCURRENCY` to
+a positive integer to allow more simultaneous startups. Each worker pass admits
+at most the available slots, even if an attempt fails immediately.
+
+Names, ports, and queue order survive application restarts. A server still booting
+or waiting for health keeps its slot until it passes verification or is removed.
+A lost startup response also keeps the slot because the container may already be
+running. A confirmed creation failure is recorded for review, allowing later
+queued servers to proceed on subsequent passes without undoing successful launches.
+
+The collection page separates ready, launching, queued, and failed servers. It
+highlights the current startup, shows each waiting server's queue position, and
+links to earlier launches when another collection occupies the available capacity.
+Every server links to its operation timeline and recovery options, and each child
+operation links back to its collection.
 
 ## Create and review a launch
 
@@ -148,6 +161,9 @@ when the original server is still registered on its assigned port and no later
 lifecycle operation has targeted that ID. It resumes observation only; it never
 recreates or restarts a container. Missing servers and later destruction attempts
 require inspection rather than replaying provisioning automatically.
+After an application restart, the worker automatically resumes observation of
+eligible interrupted startups so their occupied slots are retained. It never
+repeats container creation or deployment as part of this recovery.
 
 ## API
 
@@ -158,13 +174,17 @@ require inspection rather than replaying provisioning automatically.
 - `PUT /api/blueprints/:id`: edit `{ name, description?, entries }`. All entries
   use the latest promoted setup when launched.
 - `DELETE /api/blueprints/:id`: remove a library entry.
-- `POST /api/deployment-collections/preview`: preview `{ blueprintId }`.
+- `POST /api/deployment-collections/preview`: preview `{ blueprintId }`, including
+  the configured `launchConcurrency`.
 - `POST /api/deployment-collections`: atomically queue `{ previewId, keys? }`,
   where `keys` maps exact preview server IDs to optional replacement keys.
   A satisfied preview returns `{ ok: true, collectionId: null }` with HTTP 200,
   without creating a collection, saving keys, or kicking the worker.
-- `GET /api/deployment-collections`: list collection progress summaries.
-- `GET /api/deployment-collections/:id`: collection and per-server progress.
+- `GET /api/deployment-collections`: list collection progress summaries with
+  separate `queued`, `provisioning`, and `verifying` counts.
+- `GET /api/deployment-collections/:id`: collection and per-server progress,
+  each waiting server's global `queuePosition`, and the shared queue's concurrency,
+  active startups, and queued count.
 - `POST /api/deployments/preview`: preview `{ game, mapSlug }` or `{ deploymentId }`
   for a new single server using the latest promoted setup. All blueprints, including one-server
   targets, must use the collection endpoint so existing servers count correctly.