fix(windows): detect reserved paths before update autostash

[Pukujan]

Fixes #57081.

Summary

Adds a Windows preflight check before the update auto-stash step to detect reserved device-name paths such as nul.

On Windows, Git can hang or prompt interactively during git stash when an untracked reserved path exists in the working tree:

Ignoring path nul
Unlink of file 'nul' failed. Should I try again? (y/n)

This caused hermes update to appear stuck at:

-> Local changes detected - stashing before update...

Behavior after this change

Instead of invoking git stash and potentially hanging, Hermes fails fast with a clear Windows-specific message and a safe local workaround.

The fix does not automatically delete files, modify .git/info/exclude, reset the repo, clean the repo, or restore stashes.

Safety note

Manual recovery commands such as git reset --hard, git clean -fdx, clearing stashes, or declining stash restore can discard uncommitted local changes inside the Hermes install repo. This PR intentionally avoids those destructive actions and only detects/reports the unsafe path before autostash.

Follow-up idea

A future PR could add a self-updating manifest/update-state file for Hermes updates. That manifest could track installed SHA, target SHA, Python version, dependency-install status, pre-update snapshot, backup path, autostash state, process-lock detection, and recovery status.

That would make updates more resumable/idempotent and could support a future hermes update doctor or hermes repair command for partial updates, locked executables, failed dependency installs, and stale update stashes.

Testing

• python -m py_compile hermes_cli\\main.py tests\\hermes_cli\\test_update_autostash.py
• python -m ruff check hermes_cli\\main.py tests\\hermes_cli\\test_update_autostash.py
• python -m pytest tests\\hermes_cli\\test_update_autostash.py -k "windows_reserved_component or aborts_before_stash or stash_local_changes_if_needed"
• Attempted full python -m pytest tests\\hermes_cli\\test_update_autostash.py; 46 passed and 4 failed on existing Windows test assumptions around git -c windows.appendAtomically=false command shape, outside this change.

[teknium1]

Thanks for the focused, non-destructive Windows recovery path. The CLI premise is still present on current main: hermes_cli/main.py:6454-6489 calls git stash push --include-untracked after detecting a dirty tree, and the linked issue documents ?? nul reaching that flow.

Problems

• The managed Windows installer has the same live autostash sequence: scripts/install.ps1:1347 checks dirty status and scripts/install.ps1:1365 runs git stash push --include-untracked without a reserved-path preflight. Re-running the installer on an existing managed checkout can therefore retain the same nul failure mode.

Suggested changes

• Apply the same non-destructive preflight to scripts/install.ps1 before line 1365, plus a focused PowerShell regression test. Do not automatically clean, reset, or modify excludes.
• The proposed Python helper remains the right placement for hermes update, since both current CLI update paths call it at hermes_cli/main.py:9736 and :9770.

Automated hermes-sweeper review.

[chancelu]

Hi @Pukujan — after reviewing both approaches, I think your fail-fast strategy is the right call. I'm the author of #71841 and I plan to close it in favor of yours.

Two things from #71841 that might be worth folding into yours:

1. Manual deletion workaround using \\\\?\\ prefix: Your current workaround suggests adding to .git/info/exclude, which is great. If you also want to offer a "delete the file" option in the error message, note that on Windows del nul fails because the OS intercepts it as a device name. The \\\\?\\ extended path prefix bypasses this check:

   import os
   os.remove(r"\\\\?\\C:\\\\full\\\\path\\\\to\\\\nul")

   This might be useful to mention for users who actually want the file gone.

2. Repro confirmation: I confirmed the hang on Windows 11 Pro (Chinese locale, GBK encoding) with a 0-byte nul file. git stash push --include-untracked hangs indefinitely (>30 min) because git tries to read the path and Windows opens the NUL device instead. Your preflight check would catch this before the hang.

Happy to help review or test if needed.