fix(file_state): sibling stale-warning now guides worktree isolation

[albert748]

Context

When concurrent Hermes sessions edit the same git repository, FileStateRegistry.check_stale() warns the model that a sibling subagent modified a file it had read. A real incident (two sessions clobbering each other on the same file) showed the warning alone is not enough: it only says "Re-read the file" — it never tells the model there is an active sibling session, that parallel edits carry clobber risk, or what to do about it.

Change

Both sibling-warning branches in tools/file_state.py::check_stale (Case 1a "sibling wrote, agent never read" and Case 1b "sibling wrote after agent's last read") now append a short collaboration-guidance line:

• names the risk: concurrent agents may keep editing this repo;
• gives the escape hatch: isolate in a git worktree (hermes -w / git worktree add) or coordinate with the sibling session.

The added text is intentionally short, generic (no project-specific skill names), and stays warning-only — consistent with the existing "warn, don't block" contract of check_stale.

Relationship to #65605

#65605 (fix: block stale write_file overwrites) is the complementary direction: it makes write_file fail closed on stale baselines by changing tools/file_tools.py and the staleness plumbing. This PR touches only warning text in tools/file_state.py and does not conflict with it — both can land independently; if #65605 lands first, this guidance still improves the surviving warning path.

Tests

• tests/tools/test_file_state_registry.py: 7 passed (existing sibling assertions still hold, warning text retains sibling + writer id)
• tests/tools/test_file_staleness.py: 6 passed

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(file_state): sibling stale-warning now guides worktree isolation

1. check_stale has no knowledge of whether the workspace is actually a Git repository, so the new "isolate in a git worktree (hermes -w / git worktree add)" hint is emitted even for users working in non-Git directories, where it is noise. Minor — since this is a suggestion inside an error string, gating it (e.g. on a .git presence probe) or keeping the message generic would avoid confusing non-Git users.
2. Otherwise a pure message change with no behavioral impact; the two message variants stay in sync with each other, which is the only maintenance risk worth watching.