feat: add provisioning lifecycle actions

Rename Deployments to Provisioning with compatible redirects and APIs. Add durable Start, Restart, Stop, and Rebuild operations alongside Create and Destroy; rebuild wipes the instance and recreates it in the same slot and port.

Add lifecycle, migration, recovery, and Komodo command tests. Type checks and production build pass; the full suite retains a telemetry assertion failure reproduced on the unchanged branch.

Refs #39

README.md

@@ -127,9 +127,9 @@ 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.
 
-## Deployment blueprints and launch previews
+## Provisioning blueprints and launch previews
 
-Deployments also offers **House Party Protocol**: review the entire fleet and queue
+Provisioning also offers **House Party Protocol**: review the entire fleet and queue
 destruction in one action. This includes queued creations and reuses pending
 destruction requests. Each server waits for a fresh zero-player reading; occupied
 or unreachable servers remain queued. Containers, server files, and registrations
@@ -142,7 +142,7 @@ If deletion fails after Komodo removal, the operation detail page offers
 repeating Komodo deletion. Requesting destruction again also resumes that cleanup.
 Recovery is blocked if a newer operation exists for the same server name.
 
-Deployments includes a blueprint builder for whole server collections: choose
+Provisioning includes a blueprint builder for whole server collections: choose
 multiple T5/T6 maps and set the desired total lobbies for each. **Conform fleet**
 counts existing and queued servers and creates only the shortfall. The preview
 shows target/existing/missing counts and IDs, ports, and key requirements for new
@@ -348,10 +348,25 @@ RCON parsing (fake UDP socket).
 
 5. Load the app on the LAN or over tailscale (no web-app auth by design).
 
-## Campaigns and server deployments
+## Campaigns and provisioning
 
 Campaigns (`/campaigns`) tracks script/config updates, drift reconciliation, restart progress, file diffs, and rollbacks. Existing campaign records are preserved in the original database tables. The campaign API lives at `/api/campaigns`; legacy detail API endpoints remain available for compatibility.
 
-Deployments (`/deployments`, `/api/deployments`) now tracks server creations and destructions with live stages and persistent history, including failures, warnings, and interrupted operations. History starts with operations performed after this update and survives server removal. New creation requests return HTTP 202 with a deployment ID and open the deployment detail page. Creation is complete only when Komodo reports healthy, RCON responds successfully, and the RCON map exactly matches the selected map. Queued requests reserve their server name and port; queued creation and pending health checks survive application restarts. The detail page records startup progress and explains any health or map mismatch that is still blocking completion.
+Provisioning (`/provisioning`, `/api/provisioning`) tracks Create, Start, Restart, Rebuild, Stop, and Destroy operations with live stages and persistent history, including failures, warnings, and interrupted operations. History starts with operations performed after this update and survives server removal. New creation requests return HTTP 202 with an operation ID and open the provisioning detail page. Creation is complete only when Komodo reports healthy, RCON responds successfully, and the RCON map exactly matches the selected map. Queued requests reserve their server name and port; queued creation and pending health checks survive application restarts. The detail page records startup progress and explains any health or map mismatch that is still blocking completion.
 
-Each server deployment opens a detail page with its flow and timestamped activity. Destroy uses an in-app confirmation modal and immediately returns a queued deployment (`DELETE /api/servers/:name` returns HTTP 202 with `deploymentId`). The worker waits for a fresh RCON player count of zero before teardown; occupied or unreachable servers remain queued and are checked each worker tick. Waiting requests survive application restarts, while interrupted teardown is marked for inspection. Completed destruction stays on the deployment detail page.
+Each server deployment opens a detail page with its flow and timestamped activity. Destroy uses an in-app confirmation modal and immediately returns a queued deployment (`DELETE /api/servers/:name` returns HTTP 202 with `deploymentId`). The worker waits for a fresh RCON player count of zero before teardown; occupied or unreachable servers remain queued and are checked each worker tick. Waiting requests survive application restarts, while interrupted teardown is marked for inspection. Completed destruction stays on the provisioning detail page.
+
+
+Use **Provisioning → Manage server**, or a server’s **Server actions**, to start,
+restart, stop, or rebuild an existing instance. **Rebuild destroys and creates in
+place**: the old container, Komodo deployment, server registration, and all server
+files are deleted. A fresh instance uses the same server ID, map, and port with
+the latest promoted setup. No old instance files are carried forward. The key
+stored separately in **Keys** must be available before teardown. Stop retains the
+instance so Start can bring it back. Disruptive operations wait for a fresh empty
+reading or a confirmed stopped container, and completion requires verification.
+See [Provisioning](docs/provisioning.md) for lifecycle behavior and recovery.
+
+Existing `/deployments` page links redirect to `/provisioning`, preserving filters
+and operation IDs. Legacy `/api/deployments` endpoints and stored history remain
+compatible.