fix(cli): add timeout to git stash during update

[liuhao1024]

What does this PR do?

Add a 120-second timeout to git stash push --include-untracked in the update flow. On Windows, this command can hang indefinitely when files are locked by other processes (antivirus, gateway, etc.), causing hermes update to appear stuck for hours.

When the timeout is reached, the update proceeds without stashing and prints guidance for manual stash/reset.

Related Issue

Fixes #57081

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• hermes_cli/main.py: Added timeout=120 to the git stash push --include-untracked subprocess call in _stash_local_changes_if_needed(). Catches subprocess.TimeoutExpired and returns None (skip stashing) with actionable guidance.
• tests/hermes_cli/test_update_autostash.py: Added test_stash_local_changes_if_needed_returns_none_on_timeout verifying the timeout behavior.

How to Test

1. Run pytest tests/hermes_cli/test_update_autostash.py -q — all 34 tests should pass.
2. On a system with locked files (e.g., Windows with antivirus scanning), hermes update should no longer hang indefinitely. After 120s, it prints a warning and proceeds.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 26.4.1

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

[alt-glitch]

This was generated by AI during triage.

Related: #42862 adds timeouts to all 11 git subprocess calls in the stash-management flow; this PR is a narrower subset targeting just the git stash push --include-untracked hang on Windows (locked files). Not a duplicate - a maintainer may prefer the focused fix or the broader one. Related: #57081 (issue).

[teknium1]

Thanks for targeting a real Windows update hang. Current main still has the unbounded stash call at hermes_cli/main.py:6485-6489.

Problems

• Returning None on timeout makes cmd_update treat the operation as if there were no stash, while the local changes are still present. A later nonzero git pull --ff-only is handled as divergence and reaches git reset --hard origin/<branch> at hermes_cli/main.py:9900-9912; that fallback’s own comment assumes changes were already stashed. This can discard unstashed tracked edits.
• The new test covers the helper return only. It does not cover the subsequent update path or prevent the reset fallback after a timeout.

Suggested changes

• Abort the update through a distinct safe failure path after TimeoutExpired; do not use the no-stash sentinel while the tree remains dirty.
• Add a cmd_update regression test proving a timeout cannot reach pull/reset with unstashed changes. The #57081 discussion and PR #57212 document the concrete reserved-nul Windows case and a fail-fast alternative.

Automated hermes-sweeper review.

[teknium1]

Returning None says no stash exists, but local changes remain after the timeout. If the subsequent pull is nonzero, current cmd_update falls back to git reset --hard origin/<branch> at hermes_cli/main.py:9900-9912 under the assumption changes were stashed. Please abort through a distinct safe path instead of continuing with this sentinel.