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/AGENTS.md

@@ -115,7 +115,9 @@ When the operator asks for run status, report in this order:
 
 Status details:
 - Use the same status display format for every ATVM automation status response regardless of template type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
+- Treat a status request as a request for live status by default.
 - Use the live run log on the automation VM when available.
+- If no automation is currently running, fall back to the most recent historical run artifacts and logs.
 - Use the run `build_name` as the heading/title when available.
 - Format every machine entry as `machine-name - STATUS`.
 - Put each machine on its own line; do not combine multiple machine statuses on one line.
@@ -130,6 +132,7 @@ Status details:
 - Include end time and total runtime for completed runs, or elapsed runtime for active runs.
 - Include quickest completed test runtime, longest completed test runtime, and average completed test runtime under timing details when they can be derived from the log.
 - Make the estimated completion time refer to the entire remaining run, not only the current machine/spec.
+- For categorized runs, reconstruct the status of the entire run across all category batches whether the run is still active or only historical artifacts remain.
 
 ### Automation Blacklist
 Always exclude these machines with `--exclude_partial_match` when building ATVM automation commands.