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

docs/deployment-blueprints.md

@@ -1,6 +1,6 @@
 # Deployment blueprints
 
-The Deployments page is the starting point for reusable server collections. A
+The Provisioning page is the starting point for reusable server collections. A
 blueprint describes a whole lineup: for example, two Kino lobbies, one Moon lobby,
 and two Town lobbies. Counts are desired fleet totals: existing and queued
 servers count toward each target, and only missing servers are created.
@@ -23,7 +23,7 @@ It fills deficits without changing existing servers' files.
 
 ## Build and launch a collection
 
-1. Choose **Create blueprint** on Deployments and name the lineup.
+1. Choose **Create blueprint** on Provisioning and name the lineup.
 2. Add maps from Black Ops I or II and set the desired total lobbies for each.
 3. Choose **Save & preview** (or **Preview fleet changes** on a saved blueprint).
    Choose **Fill missing servers** or **Match blueprint exactly**, then review
@@ -113,7 +113,7 @@ operation links back to its collection.
 
 ## Create and review a launch
 
-1. Choose **Single server** on Deployments (or the deploy action on the fleet).
+1. Choose **Single server** on Provisioning (or the deploy action on the fleet).
 2. Choose the current promoted setup and select a game/map, or select a blueprint.
 3. Choose **Preview launch**. Review the image reference, configuration sources,
    managed files and versions, selected map, lobby, port, and prerequisite checks.

docs/provisioning.md

@@ -0,0 +1,64 @@
+# Provisioning
+
+Open **Operations → Provisioning** for instance lifecycle work, blueprints, and
+persistent activity. Create a server using **Create server**. For an existing
+server, choose **Manage server** or open its **Server actions** menu.
+
+| Action | Behavior |
+| --- | --- |
+| Create | Create a new instance using the latest promoted files and verify container health, RCON, and the selected map. |
+| Start | Start the existing container and verify container health and RCON. |
+| Restart | Wait until empty, restart the existing container, and verify container health and RCON. |
+| Rebuild | Wait until empty, destroy the instance, delete all server files and its registration, then create a fresh instance in the same server slot and port. Verify container health, RCON, and map. |
+| Stop | Wait until empty, stop the container, and verify that Komodo reports it stopped. Keep the instance for a later Start. |
+| Destroy | Wait until empty, remove the container and Komodo deployment, then delete server files and registration. |
+
+Rebuild requires confirmation because **no instance data is preserved**. Its fresh
+files come from the latest promoted setup when creation begins, including changes
+promoted while waiting. The independently saved key in **Keys** must exist before
+teardown. Blueprint definitions, promoted artifacts, saved keys, and historical
+activity belong to Electric Cherry, and are not instance files.
+
+Rebuild reserves the original ID and port throughout teardown and creation, even
+when a lower lobby is available. It shares the existing creation queue and startup
+limit. A failed removal never proceeds to creation. Once Komodo deletion is
+confirmed, failed local cleanup offers **Resume rebuild cleanup**; creation cannot
+proceed until the old files are fully removed. An interrupted fresh startup can
+resume health verification, without repeating teardown or creation. Inspect other
+failures before making another request.
+
+Start and Restart share the rolling restart limit with campaigns, betas, and
+maintenance. A successful API reply is followed by a recovery delay and actual
+container/RCON checks. Failed or ambiguous restart requests retain their recovery
+slot and are not automatically replayed. Automated restart submissions also appear
+in Provisioning history. Stop requires an explicit stopped container state; an
+unreachable Komodo API is not evidence that a stop succeeded.
+
+Disruptive operations require a fresh zero-player RCON result, unless Komodo
+positively reports a stopped container. Runtime actions wait for conflicting
+campaign, beta, maintenance, or provisioning work. Duplicate pending requests for
+the same action return the existing operation; a different action returns a
+conflict. Requests and events survive application restarts.
+
+## Routes and compatibility
+
+- `/provisioning`: active operations, blueprints, and history filtered by action.
+- `/provisioning/:id`: operation stages, errors, timestamps, and activity.
+- `/provisioning/collections/:id`: collection progress.
+- `GET /api/provisioning`: lifecycle history (`deployments` response property).
+- `POST /api/provisioning`: queue `{ "server": "t5_zombie_theater_1", "action": "start" }`.
+  Supported actions are `start`, `restart`, `rebuild`, and `stop`. Returns HTTP 202
+  with `deploymentId`. Create continues through `POST /api/servers`; Destroy uses
+  `DELETE /api/servers/:name`.
+- `/api/provisioning/:id`, `/:id/resume`, `/:id/cancel`, `/preview`, and
+  `/house-party` preserve the existing operation, recovery, removal cancellation,
+  launch preview, and fleet destruction APIs.
+
+Old `/deployments` pages redirect to their `/provisioning` equivalents, preserving
+query parameters. `/api/deployments` remains compatible, including old campaign
+detail endpoints. No history or IDs are renamed or discarded.
+
+Start and Stop use Komodo's corresponding runtime commands. Rebuild uses full
+destruction and creation, not Komodo's redeploy command. See the
+[Komodo execute API](https://docs.rs/komodo_client/latest/komodo_client/api/execute/index.html)
+for the underlying container operations.

docs/ui-ux-review.md

@@ -122,7 +122,7 @@ Add **Cancel queued removal** while the operation is still waiting, with a preci
 
 Acceptance: an operator can withdraw a waiting removal, and a race with worker execution cannot leave the UI claiming cancellation after removal has begun.
 
-Sources: [DestroyServerModal](../src/lib/ui/components/DestroyServerModal.svelte), lines 36–40; [HousePartyDialog](../src/lib/ui/components/HousePartyDialog.svelte), line 51; [deployment detail](../src/routes/deployments/[id]/+page.svelte), lines 110–123. Existing consequence confirmations should remain.
+Sources: [DestroyServerModal](../src/lib/ui/components/DestroyServerModal.svelte), lines 36–40; [HousePartyDialog](../src/lib/ui/components/HousePartyDialog.svelte), line 51; [deployment detail](../src/routes/provisioning/[id]/+page.svelte), lines 110–123. Existing consequence confirmations should remain.
 
 ### 8. Report partial success as a distinct outcome — P1 · Source
 
@@ -310,7 +310,7 @@ Use “server” consistently for the managed unit; introduce “lobby” as its
 
 Acceptance: primary tasks are identifiable by placement and wording, and multiple browser tabs are distinguishable. Contrast should be measured before claiming a conformance result.
 
-Sources: [tokens](../src/lib/ui/styles/tokens.css), lines 57–71, 86–87; [BetaPlanBuilder](../src/lib/ui/components/BetaPlanBuilder.svelte); [navigation and shortcuts](../src/routes/+layout.svelte), lines 37–65; [deployment blueprint actions](../src/routes/deployments/+page.svelte), lines 125–132.
+Sources: [tokens](../src/lib/ui/styles/tokens.css), lines 57–71, 86–87; [BetaPlanBuilder](../src/lib/ui/components/BetaPlanBuilder.svelte); [navigation and shortcuts](../src/routes/+layout.svelte), lines 37–65; [deployment blueprint actions](../src/routes/provisioning/+page.svelte), lines 125–132.
 
 ### 26. Make investigation and handoffs easier over time — P3 · Opportunity