Clarify server actions and group maintenance failures

docs/guides/provisioning.md

@@ -5,7 +5,11 @@ activity. **Fleet → Collections** owns reusable lineups and collection launch
 progress; their individual operations remain visible in Provisioning.
 Provisioning owns the queues, safety checks, execution, and
 recovery for all six actions. Create a server using **Create server**. For an existing
-server, choose **Manage server** or open its **Server actions** menu.
+server, use its visible **Restart server** or **Start server** action, or open
+**More actions**. Only actions supported by current host and container evidence
+are shown. Confirmations name the server and its current players and round;
+disruptive actions still wait for a fresh empty-lobby check. **Manage server**
+on the operations page offers the same actions for a selected server.
 
 **Create server** opens one dialog with game and map choices followed by automatic
 readiness checks. Blockers explain what needs attention before launch. Runtime
@@ -29,18 +33,18 @@ retries when a response is lost.
 | Restart | Wait until empty, restart the existing container, and verify container health and RCON. |
 | 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. |
+| Remove | Wait until empty, remove the container and its files through the host agent, then retire the instance and registration. |
 
 ## Safety and verification
 
 ### Beta ownership and rebuilds
 
-Servers linked to a running or ready-to-promote beta cannot be destroyed or
+Servers linked to a running or ready-to-promote beta cannot be removed or
 rebuilt. Promote or roll back the beta first, including paused or failed test
 plans. Fleet removal and exact collection launches queue nothing if any server
 selected for removal belongs to an active beta. Provisioning checks again before
 teardown; already queued removals wait while their server belongs to an active
-beta. Opening a beta also requires cancelling or finishing any pending destruction
+beta. Opening a beta also requires cancelling or finishing any pending removal
 or rebuild on its selected servers.
 
 Rebuild requires confirmation because **no instance data is preserved**. Its fresh
@@ -87,7 +91,7 @@ Administrators can add and remove available keys in **Admin → Keys**;
 assigned keys cannot be removed. Existing keys are migrated into their game
 pool, retaining assignments for existing servers and pending work. If a legacy
 rebuild has an uncertain result and used a different key, both possible keys
-remain reserved until that server is destroyed. Labels are for identification
+remain reserved until that server is removed. Labels are for identification
 only and do not change the hostname registered with Plutonium.
 
 ### Player checks and administrator overrides
@@ -210,7 +214,7 @@ heartbeat or completion-time promises.
   `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.
+  launch preview, and fleet removal APIs.
 - `POST /api/provisioning/:id/cancel` cancels any active create, start, restart,
   rebuild, stop, or destroy job, including health verification. It releases that
   job's recovery capacity and prevents further steps; completed effects are not
@@ -250,7 +254,7 @@ See [native host management](native-hosts.md) for command delivery and recovery.
 
 Admin → Settings groups Concurrency separately from history and storage settings,
 with one Save changes action for all pending edits. Existing fleet restart, startup
-and removal limits continue to apply. Additional per-host restart, startup and destruction limits, a combined
+and removal limits continue to apply. Additional per-host restart, startup and removal limits, a combined
 lifecycle limit, a rebuild limit, and a limit on hosts preparing game files default
 to 0 (no additional cap), preserving existing throughput on upgrade.