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

@@ -29,6 +29,7 @@ Reference/inventory material:
 - `*-examples.md` files:
   - Reusable command examples and commonly used option combinations.
   - Keep generic; avoid dated one-off run outcomes.
+  - Keep command-focused; move workflow rules, defaults, blacklist policy, and reporting requirements into the corresponding `*-guide.md` or `*-runs.md` files.
 
 ## Setup Track: Required Behavior
 Use `atvm-setup-script-guide.md` as the procedure source and keep behavior aligned with `atvm-setup-script.sh`.
@@ -113,6 +114,7 @@ When the operator asks for run status, report in this order:
 8. Estimated completion time.
 
 Status details:
+- Use the same status display format for every ATVM automation status response regardless of template type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
 - Use the live run log on the automation VM when available.
 - Use the run `build_name` as the heading/title when available.
 - Format every machine entry as `machine-name - STATUS`.