Document ATVM status defaults for live and categorized runs

Clarify ATVM automation status handling so status requests default to live run data from the automation VM. If no automation is active, fall back to the most recent historical run artifacts and logs.

Also document that categorized runs must always be reconstructed as a single full run across all category batches or cloud sub-runs, rather than reporting only the current or latest batch.

Update:
- atvm/atvm-automation-guide.md
- atvm/AGENTS.md
- atvm/atvm-automation-runs.md

atvm/atvm-automation-runs.md

@@ -135,3 +135,13 @@ This file stores run-specific examples only when a run produced a new learning r
   - If the requested config file is missing, stop immediately and report the missing filename.
   - Do not search the automation VM for alternate config files.
   - Do not switch to another config unless the operator explicitly instructs it.
+
+## Run Learning: 2026-03-16 (Status requests default to live view with whole-run historical fallback)
+- Observed requirement:
+  - When the operator asks for ATVM automation run status, they want live status by default.
+  - If no automation is currently running, the status response must fall back to the most recent historical run.
+  - For categorized runs, the response must still cover the entire run rather than only the latest category batch or cloud sub-run.
+- Action for future runs:
+  - Treat every ATVM status request as a request for live run status unless the operator explicitly asks for something else.
+  - If no automation is active, reconstruct status from the most recent historical run artifacts and logs.
+  - For categorized runs, always aggregate all same-run category batches so the response covers the full run scope.