Unify retained operation history in Activity

docs/guides/maintenance.md

@@ -17,9 +17,11 @@ Campaigns retain managed-file deployment evidence; Collections define lineups.
   when the running revision is unverified.
 - **Policies & schedules** controls health recovery, configuration drift, automatic
   Plutonium updates, and the optional daily restart schedule independently.
-- **Activity** combines recovery findings, update results, and scheduled restarts.
-  Follow a finding for evidence and attempts, or its Provisioning operation for
-  execution progress. Cancel unsubmitted runtime restarts here.
+- **Activity** uses the shared Activity log, scoped to maintenance and recovery.
+  Filter retained findings, update results, and scheduled restarts in one timeline.
+  Follow a finding for evidence or an operation for execution progress. Use
+  Overview’s **Active work & attention** to cancel waiting work or retry failed
+  verification after inspection.
 
 Fleet and server details link their revision indicators to Maintenance. Failed
 runtime maintenance appears in Fleet attention, even when the underlying restart

docs/guides/provisioning.md

@@ -1,7 +1,8 @@
 # Provisioning
 
-Open **Activity → Operations** for instance lifecycle work and persistent
-activity. **Fleet → Collections** owns reusable lineups and collection launch
+Open **Activity → Activity log** for retained lifecycle, host, campaign, and
+maintenance history. Use **Manage servers** from that page or command search
+for server queues, bulk cancellation, and lifecycle actions. **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