Recover unhealthy containers during create and rebuild

docs/guides/provisioning.md

@@ -71,6 +71,14 @@ making another request.
 
 ### Health and runtime checks
 
+If the host agent explicitly reports an unhealthy container during Create or
+Rebuild verification, that operation forces one restart, then forces one rebuild
+if the container remains unhealthy. Recovery preserves the selected launch files,
+credentials, server identity, and port. If both attempts leave it unhealthy, the
+operation fails for inspection instead of repeating recovery. Starting, restarting,
+and unknown container states continue waiting for readiness. This requires host
+agent 1.8.1 or newer.
+
 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
 manifest and records the runtime revision for fleet and server version status as
@@ -114,6 +122,11 @@ campaign, beta, maintenance, or provisioning work. Duplicate pending requests fo
 the same action return the existing operation; a different action returns a
 conflict. Requests and events survive application restarts.
 
+Rebuild and recovery within Create or Rebuild treat an explicitly unhealthy
+container as empty without requiring a player count. The agent checks health
+again before disruption; if the container has recovered, normal player checks
+apply. This exception does not apply to unknown health or other lifecycle actions.
+
 For a failed container stuck waiting for player status, an administrator can open
 its queued or waiting **Restart**, **Stop**, **Rebuild**, or **Destroy** operation
 and choose **Admin override…**. The confirmation modal explains the interruption