fix(agent): suppress stale mutation verifier warnings

[aftership-bot-vlt-platform]

Summary

• track a local stat fingerprint when a file mutation fails
• suppress the verifier footer when the target is later changed by terminal/CLI or another external path
• retain warnings for unchanged or non-local/unverifiable targets

Reproduction

A protected patch to ~/.hermes/config.yaml can fail, followed by a successful hermes config set command. The config is modified, but the verifier previously still claimed the file was not changed because it only observed file-tool success.

Verification

• uv run --extra dev pytest tests/run_agent/test_file_mutation_verifier.py -q -o "addopts=" — 44 passed
• turn-finalizer regression set — 28 passed
• combined post-commit regression set — 72 passed
• uv run --extra dev ruff check run_agent.py agent/turn_finalizer.py tests/run_agent/test_file_mutation_verifier.py — passed
• exact external-mutation reproduction — passed
• git diff --check — passed

Risk

Stat-based comparison intentionally avoids hashing large files. Remote backends fail closed and retain the warning.

[alt-glitch]

This was generated by AI during triage.

Related: #53165 addresses the same stale mutation-verifier warning with backend-aware content fingerprints. This PR uses a smaller local stat-fingerprint approach; maintainers should choose the desired verifier semantics.

[teknium1]

Thanks for isolating the stale-verifier case and adding local/remote regression coverage. The current-main premise is valid: run_agent.py:2910-2916 tracks only write_file/patch, while agent/turn_finalizer.py:304-310 renders any remaining failure, so a later terminal recovery cannot currently clear the warning.

Problems

• run_agent.py:2926 fingerprints st_mode and st_ctime_ns. A metadata-only operation such as chmod changes those fields without changing content, yet run_agent.py:2994-2998 would clear the warning. The footer's assertion that the requested mutation did not land can therefore be hidden by an unrelated metadata change.
• The linked #53165 records the stronger recovery contract: backend-aware content identity plus a successful foreground fallback. This PR instead treats any observable local change as recovery; the member comment on this PR explicitly asks maintainers to choose the semantics.

Suggested changes

• Add a metadata-only regression (chmod/chown) and retain the footer unless contents changed.
• Align the chosen implementation with an explicit recovery contract; if fallback causality is required, capture the resolved backend target and compare it around the successful foreground fallback.

Automated hermes-sweeper review.

[teknium1]

This fingerprint includes st_mode and st_ctime_ns, so a metadata-only chmod/chown after a failed patch changes the fingerprint and clears the footer even though file contents were not recovered. Please require a content change (and add a metadata-only regression) before suppressing the warning.