Offer rebuild retry for failed creation commands

docs/guides/collections.md

@@ -287,12 +287,22 @@ server launch until the health checks pass.
 
 For failed or interrupted creations, **Resume health verification** appears only
 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.
+lifecycle operation has targeted that ID. Native commands must have completed
+before readiness verification can resume. If the container is unhealthy, the
+operation may continue its remaining automatic restart and rebuild recovery steps.
+
+When the host conclusively reports that the initial creation command failed,
+**Retry with rebuild** starts a new provisioning operation for the same lobby and
+port. It deletes the container and instance files and uses the latest promoted
+setup. Normal player safety, capacity, and protected work checks still apply.
+The original failure stays in history and links to the recovery operation.
+This retry is unavailable for unknown command results, replacement instances,
+cancelled creation cleanup, or a later operation on the same server.
+
+After an application restart, the worker reconciles the original host command
+before continuing eligible interrupted startups. Unknown command results retain
+their original command ID and occupied slots until the host confirms the outcome.
+Missing server registrations and later destruction attempts require inspection.
 
 ## API
 
@@ -339,7 +349,9 @@ there while preserving query parameters.
 - `POST /api/servers`: existing request plus optional `previewId`; the game and
   map must match that preview. `expectedName` remains supported.
 - `GET /api/deployments/:id`: includes `recipe`, `blueprintName`, and
-  `canResumeVerification` for lifecycle operations.
+  `canResumeVerification` and `canRetryWithRebuild` for lifecycle operations.
 - `POST /api/deployments/:id/resume`: resume eligible creation health checks.
+- `POST /api/provisioning/:id/retry-rebuild`: request a new rebuild for an eligible
+  failed creation and link it from the original operation.
 
 Collection launches begin processing immediately after all requests are queued.