atvm: resolve automation status from local workflow artifacts

Clarify that ATVM automation status requests refer to the local atvm
folder workflow and the automation VM at 192.168.3.190, not Cirrus
project operations such as the atvm - cypress project.

Update the ATVM guide and AGENTS notes to prefer local evidence in this
order when reporting status:
- active runner processes
- live automation VM files
- shell history for the last launch command
- historical reporter artifacts

Record the new run learning in atvm-automation-runs.md so future status
requests use the correct source of truth.

atvm/atvm-automation-guide.md

@@ -165,9 +165,11 @@ When the operator asks for the status of an ATVM automation run, report in this
 
 Status-report expectations:
 - Use the same display layout for every ATVM automation status response regardless of test type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
+- Treat references to the "ATVM automation run" or "automation run" as referring to this ATVM folder workflow and the automation VM at `192.168.3.190`, not to Cirrus project operations such as the `atvm - cypress` project.
 - Treat a status request as a request for live status by default.
 - Use the live automation VM state when available.
 - If no automation is currently running, fall back to the most recent historical run artifacts and logs.
+- Prefer local automation evidence in this order: active runner processes, live automation-VM files, shell history for the last launch command, then historical reporter artifacts.
 - Derive the heading/title from the run `build_name` when available.
 - Format every machine entry as `machine-name - STATUS`.
 - Put each machine on its own line; never combine multiple machines into one paragraph or comma-separated line.