fix(files): avoid false stale writes from Windows stat/fstat ctime differences

[MariusYvard]

What does this PR do?

Fix false incomplete/stale-write refusals when Windows os.stat(path) and os.fstat(fd) report different st_ctime_ns values for the same unchanged file.

_file_version() currently compares descriptor metadata directly with path metadata. On the tested Windows 11 / Python 3.14.7 environment the ctime disagreement makes it return None, so a complete read or a successful write can fail to establish the full-current-content baseline required for a subsequent overwrite.

Changes made

• Compare path metadata before/after against itself and descriptor metadata before/after against itself, retaining device, inode, size, mtime and ctime change detection within each API.
• Bind the hashed descriptor to the path using device, inode, size and mtime, without requiring cross-API ctime equality.
• Return path metadata plus SHA-256 so existing _file_metadata() comparisons remain compatible.
• Preserve digest-based stale-write refusal, including same-size edits with restored mtime and file replacements. This does not make the existing check-to-write interval atomic.

Only tools/file_tools_read_tracking.py and tests/tools/test_file_snapshot.py change. Two parameterized behavioral tests cover stable/mutating snapshots and real registry-dispatched read/write/edit/replacement sequences. The latter has platforms("any") so Windows CI selects it.

Existing work checked

All-state searches included st_ctime_ns, fstat, file_tools_read_tracking, stat/fstat/write and Windows snapshot terms. Adjacent PRs were inspected:

• fix(tools): a rebound task id in one conversation is not a sibling subagent #121914 changes conversation/task ownership in sibling-write diagnostics, not snapshot metadata consistency.
• fix(agent): suppress stale mutation verifier warnings #65584 changes stale mutation-verifier warnings.
• fix(config): key load_env()'s cache on content digest, not mtime/size #103361 concerns config/environment caching, not file-tool write baselines.
• fix(file-tools): check remote binary overwrites on the execution target, not the controller #124106 concerns remote binary write guards.

No matching open snapshot-consistency repair was found. No new issue is claimed or closed.

Verification

Windows 11, Python 3.14.7, PM-built environment, canonical runner with explicit HERMES_PYTHON:

scripts/run_tests.sh tests/tools/test_file_snapshot.py tests/tools/test_file_staleness.py tests/tools/test_known_file_write_baseline.py tests/tools/test_binary_document_write_guard.py tests/tools/test_remote_binary_write_guard.py -j 2
# 60 passed, 0 failed

• New regression file copied into an unchanged production-code checkout: 9 failed, 18 passed. This includes the real read/write baseline failures and deterministic metadata cases. Fixed branch: 27 passed in that file.
• Existing staleness suite: 5 failed, 2 passed during baseline audit; 7 passed with the fix.
• Final Windows-marked regression selection: 3 passed (-m platforms).
• Actual scoped Windows CI file selector selected the new file; the native platform gate accepted any.
• Ruff and git diff --check: passed.
• Independent scope and quality/security reviews: passed.

Not claimed: complete repository suite, local POSIX execution or upstream exact-head CI success.

Checklist

• Read contributing/area guidance and checked existing PRs.
• Narrow conventional commit; no unrelated changes.
• Regression failure verified against unchanged production code.
• Tests preserve real external-edit/replacement refusal and successful consecutive writes.
• Windows regression explicitly wired into its CI lane.
• Full repository suite passes (not run).
• Required exact-head upstream CI passes.
• No config, schema or user-documentation change needed.

AI assistance was used for investigation, implementation and independent reviews under the contributor's direction.