Remove Komodo backend in favor of native hosts

docs/deployment-blueprints.md

@@ -104,7 +104,8 @@ the current shortfall too.
 
 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.
+until the host agent confirms container health, game status and the selected map
+are verified, and RCON reports a current Plutonium revision.
 Only then can the next queued server start. Set **Concurrent server startups** in **Settings → Fleet settings** to
 a positive integer to allow more simultaneous startups. Each worker pass admits
 at most the available slots, even if an attempt fails immediately.
@@ -137,10 +138,10 @@ another launch takes the lobby, submission stops before saving the key;
 refresh the preview and review the newly assigned ID. Refreshing a preview clears
 the typed key so it cannot accidentally be saved against a different lobby.
 
-Komodo connection settings, target host, RCON configuration, config filename,
-lobby availability, and port availability are checked locally. These checks do
-not probe the host or verify game files, images, Docker volumes, firewall
-rules, or credentials. Container and RCON verification happen after provisioning.
+Host selection, game-file versions, runtime configuration and lobby availability
+are checked before queueing. Provisioning assigns host capacity and physical
+ports when dispatching. The host agent performs container and RCON verification
+locally after launch. See [native hosts](native-hosts.md) for readiness checks.
 T6 variants retain their exact catalog slug and launch ruleset; RCON health checks
 verify the engine map, not the variant's start location.