fix(update): keep passive checks from locking shallow clones

[sppburke-DA]

What

Official-checkout passive update checks now compare local HEAD with the public upstream tip through the existing read-only git ls-remote path for both HTTPS and SSH origins. They no longer run a mutating git fetch.

Fork checkouts keep the existing origin-fetch behavior, including exact counts for full clones and presence-only reporting for shallow clones.

Why

On a shallow installer checkout, git fetch --depth 1 creates .git/shallow.lock. The passive checker has a 10-second timeout; when that timeout kills Git, the lock can survive and block the real update path:

fatal: Unable to create .../.git/shallow.lock: File exists.

This was observed with a nine-day-old orphaned lock on an ARM64 git install and reproduced again by running hermes --version: the passive fetch reached its timeout, left shallow.lock, and the immediately following hermes update --check failed. No Git process held either lock afterward.

A public ls-remote can still time out or fail offline, but it never mutates or locks the checkout, so a passive freshness check cannot strand a future update.

Related to #3523 and complementary to #63041, which covers index.lock preflight on the mutating updater path.

Validation

• scripts/run_tests.sh tests/hermes_cli/test_update_check.py -q — 16 passed
• All 10 update-check/version/banner integration files — 186 passed
• uv run ruff check hermes_cli/banner.py tests/hermes_cli/test_update_check.py
• git diff --check

The regression test covers both official HTTPS and SSH origin forms and asserts that neither emits any git fetch command.

[alt-glitch]

This was generated by AI during triage.

Related to #63041: that PR protects the mutating updater from an existing index.lock; this change prevents the passive banner/version check from leaving shallow.lock in an official shallow checkout.

[teknium1]

Thanks for the focused update-check fix. The premise is present on current main: hermes_cli/banner.py:197 only bypasses mutation for the official SSH remote, while the official HTTPS origin proceeds to git fetch at hermes_cli/banner.py:212-224, adding --depth 1 for shallow clones. The proposed canonical official-remote predicate routes both forms through the existing read-only ls-remote comparison, and tests/hermes_cli/test_update_check.py:100-137 verifies both forms emit no fetch.

The PR base 594308d4 is an ancestor of current main, no later main commit touched either changed file, and the merge-tree check reported no conflict.

Automated hermes-sweeper review.

[teknium1]

Thanks @sppburke-DA — main has landed most of this direction: official SSH-remote checkouts now do a fully passive probe (HTTPS ls-remote + compare API, no mutating fetch — hermes_cli/banner.py), and the remaining HTTPS-official fetch is branch-scoped and --depth 1-preserving, so it cannot unshallow the checkout. The lock-wedge motivation (stale .git/shallow.lock blocking every later fetch) is being fixed at the root separately by salvaging #75168/#80501 (fetch-time lock self-heal). Closing as superseded on main — the ls-remote passive-probe idea is exactly what shipped for the SSH path.