Clean up ATVM automation examples and standardize status guidance

- keep atvm-automation-examples.md limited to reusable example commands

- move example-file role guidance into AGENTS.md and atvm-automation-guide.md

- document that all ATVM automation run types use the same status display format

- record the status-format rule as a run learning in atvm-automation-runs.md

atvm/atvm-automation-guide.md

@@ -70,6 +70,7 @@ python3 ./run-sorry-cypress.py --config_file <config-file> --build_name <hyphena
 - Commonly used command examples: `atvm-automation-examples.md`
 - Keep this guide focused on run-control rules and workflow constraints.
 - Use examples as reference material only, not as default intent for new operator requests.
+- Keep `atvm-automation-examples.md` limited to reusable example commands; keep workflow rules, defaults, blacklist policy, and reporting rules in this guide or `atvm-automation-runs.md`.
 
 ## Example Option Patterns (Guide-Only)
 - Distro-scoped VM selection:
@@ -157,6 +158,7 @@ When the operator asks for the status of an ATVM automation run, report in this
 8. Estimated completion time.
 
 Status-report expectations:
+- Use the same display layout for every ATVM automation status response regardless of test type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
 - Use the live automation VM state when available.
 - Derive the heading/title from the run `build_name` when available.
 - Format every machine entry as `machine-name - STATUS`.