Remove Komodo backend in favor of native hosts

docs/provisioning.md

@@ -12,9 +12,9 @@ server, choose **Manage server** or open its **Server actions** menu.
 | Create | Create a new instance using the latest promoted files and verify container health, game status, the selected map, and the Plutonium revision. |
 | 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, game status, map, and Plutonium revision. |
-| 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 | Wait until empty, replace the instance through the host agent, preserving its server identity and port while advancing its generation. Verify container health, game status, map, and Plutonium revision. |
+| Stop | Wait until empty, stop the container, and verify that the host agent reports it stopped. Keep the instance for a later Start. |
+| Destroy | Wait until empty, remove the container and its files through the host agent, then retire the instance and registration. |
 
 Servers linked to a running or ready-to-promote beta cannot be destroyed or
 rebuilt. Promote or roll back the beta first, including paused or failed test
@@ -32,11 +32,10 @@ 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.
+limit. The agent records each operation durably, and the controller reconciles its
+receipt after reconnecting or restarting. An interrupted fresh startup can resume
+health verification without repeating the operation. Inspect failures before
+making another request.
 
 Create and Rebuild finish only after RCON reports a runtime revision at least as
 new as the current Plutonium production release. The worker checks the production
@@ -49,16 +48,15 @@ updater configuration and server logs before retrying. Telemetry can verify game
 status and map, but cannot verify the Plutonium revision.
 
 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 and game-status checks. Failed or ambiguous restart requests retain their recovery
+maintenance. A successful agent receipt is followed by actual container and game-status checks. Failed or ambiguous restart requests retain their recovery
 slot and are not automatically replayed. Stop requires an explicit stopped container state; an
-unreachable Komodo API is not evidence that a stop succeeded.
+unreachable host agent is not evidence that a stop succeeded.
 
 Disruptive operations require a fresh zero-player result from RCON or accepted
-telemetry, unless Komodo positively reports a stopped container. Fresh occupied
+telemetry, unless the host agent positively reports a stopped container. Fresh occupied
 telemetry vetoes a conflicting empty RCON reading. Reports must be received within
 90 seconds; recovery verification also excludes reports from before the submitted
-operation. Telemetry can verify the game's activity and selected map after Komodo
+operation. Telemetry can verify the game's activity and selected map after the host agent
 reports healthy. 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
@@ -78,8 +76,7 @@ after five minutes; unrelated recovery slots remain held. Drift campaigns follow
 their linked rebuild without requesting another restart. Their file evidence and
 history remain available after the instance is removed.
 
-Campaign changes queued before submission can share one restart. Changes arriving
-after submission require a new operation. A failed or interrupted request keeps
+Each campaign activation has its own durable operation and file selection. A failed or interrupted request keeps
 its original ID and never automatically replays. An explicit beta retry starts a
 new attempt, preserving prior history; paused or closed beta work cannot start a
 queued restart. Recovery of an already submitted restart continues even if its
@@ -177,7 +174,7 @@ heartbeat or completion-time promises.
   literal-text `query`, `limit` (default 25, maximum 100), an exclusive event-ID
   `cursor`, and an upper-ID `watermark`. Keep the returned watermark when loading
   more and use `nextCursor` until it is null. Begin without a watermark to include
-  newly arrived events. These reads do not probe Komodo or RCON.
+  newly arrived events. These reads do not contact host agents or probe RCON.
 
 Old `/deployments` pages redirect to their `/provisioning` equivalents, preserving
 query parameters. Collection launch links at `/provisioning/collections/:id` or
@@ -185,7 +182,6 @@ query parameters. Collection launch links at `/provisioning/collections/:id` or
 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.
+Start and Stop use durable `instance.start` and `instance.stop` host-agent
+operations. Rebuild uses `instance.rebuild` and replaces the instance files.
+See [native host management](native-hosts.md) for command delivery and recovery.