hermes - 💡(How to fix) Fix Update check cache can report stale commits-behind after git pull [1 pull requests]

Bug Description

After a git-based Hermes install is fast-forwarded to origin/main, hermes --version can keep reporting the old commits-behind count for up to six hours because ~/.hermes/.update_check is keyed only by timestamp and embedded revision. For normal git installs HERMES_REVISION is unset, so the cache does not notice that local HEAD changed.

Reproduction

1. Have a git checkout with a fresh ~/.hermes/.update_check containing a non-zero behind value.
2. Fast-forward the checkout to origin/main outside hermes update, or by any path that does not invalidate the cache.
3. Run hermes --version before the six-hour cache TTL expires.

Actual Behavior

The banner/version output still says the old value, for example Update available: 203 commits behind, even when git rev-parse HEAD origin/main is identical.

Expected Behavior

The update-check cache should be invalidated when the active checkout HEAD changes, or include the checked HEAD in the cache key. After a pull to current origin/main, hermes --version should say Up to date.

Observed Evidence

Local checkout reached HEAD == origin/main, but ~/.hermes/.update_check still contained {"behind": 203, "rev": null} and hermes --version trusted it until the cache file was deleted.

Proposed Fix

Store the active git HEAD in .update_check for local git installs and only reuse the cached result when both the embedded revision and local HEAD match. Existing cache files without this field should be treated as stale once.