fix(update): remove stale .git/shallow.lock before fetch (#75133)

[RelaxJonh]

Summary

Fixes #75133.

When an update is interrupted (network timeout, app force-close, system sleep), Git leaves behind a stale .git/shallow.lock in shallow-cloned repositories. On the next update:

1. git fetch fails with fatal: Unable to create '.git/shallow.lock': File exists
2. hermes update exits with an error
3. The Tauri/Electron GUI misinterprets this as a concurrent process: "UPDATE DIDN'T FINISH. Hermes is still running"
4. The .hermes-update-in-progress lock file is left orphaned, trapping users in an unrecoverable update loop

Fix

Before running git fetch on shallow repos, check for and remove stale .shallow.lock files. This is safe because the lock is only meaningful during an active fetch — a stale lock from a dead process has no holder.

     depth_args = ["--depth", "1"] if is_shallow else []

+    # Remove stale .git/shallow.lock left by interrupted updates (#75133).
+    if is_shallow:
+        _shallow_lock = os.path.join(_m().PROJECT_ROOT, ".git", "shallow.lock")
+        if os.path.exists(_shallow_lock):
+            try:
+                os.remove(_shallow_lock)
+            except OSError:
+                pass
+
     if branch == "main":

Testing

1. touch ~/.hermes/hermes-agent/.git/shallow.lock
2. Run hermes update
3. Verify update proceeds without "Hermes is still running" error

[teknium1]

Thanks for tracing the stale-lock failure. The report identifies a current unrecovered fetch path, but this patch needs rework before it can address it safely.

Problems

• The added cleanup is only in _cmd_update_check, reached by the --check return at hermes_cli/main.py:8991-8999. Normal apply updates fetch separately in _cmd_update_impl at hermes_cli/update_cmd.py:3295-3300, which this PR does not change.
• --check returns before shared UpdateLock acquisition (hermes_cli/main.py:8991-9020). The added existence-only unlink can therefore remove a shallow.lock belonging to a concurrent fetch.
• The PR changes only hermes_cli/update_cmd.py and adds no regression coverage for either stale or live shallow locks.

Suggested changes

• Put recovery on the applying fetch path, and make check/apply use a safe ownership or liveness rule rather than deleting any existing lock.
• Add isolated shallow-repository tests for stale-lock recovery and preservation of a live lock.

Automated hermes-sweeper review.

[teknium1]

This --check path returns before UpdateLock is acquired (hermes_cli/main.py:8991-9020), so existence alone cannot establish that this lock is stale. It can unlink a lock held by a concurrent fetch; use a shared ownership/liveness guard instead of deleting solely because the path exists.

[teknium1]

Thanks @RelaxJonh — earliest fix for this wedge (#75133), and the diagnosis in your PR body (interrupted fetch → stale .git/shallow.lock → GUI misreads it as a concurrent process) was exactly right. The fix landed via #86928, which salvages the wider variant from #80501: same self-heal, plus an age guard (10 min) and a git-process check so an in-flight fetch's lock is never removed, applied at all four wedge sites (update apply, --check, passive banner check, desktop checkUpdates()). Closing with credit — your report drove this.