fix(cli): honor main tracking remote during update checks

[kshitijk4poor]

Problem

hermes update and the CLI banner update check assume origin/main is always the canonical update source.

That is true for managed installs, but it is false in common contributor/dev checkouts where:

• origin points to a personal fork
• main tracks upstream/main

In that layout Hermes can fetch the fork, see HEAD..origin/main == 0, and incorrectly print Already up to date! even when the canonical upstream repo has newer commits.

Root Cause

The update path and banner check hardcoded origin/main instead of resolving the configured tracking remote for main.

That made update status depend on remote naming conventions rather than the repository's actual branch tracking configuration.

Fix

• added hermes_cli/update_git.py with resolve_update_remote()
• prefer branch.main.remote when it exists and the remote is configured
• fall back to origin, then upstream, then the first configured remote
• updated hermes_cli.main.cmd_update() to fetch/pull/reset against the resolved update remote
• updated hermes_cli.banner.check_for_updates() to use the same remote resolution
• made the banner cache remote-aware so stale cached results from a different remote do not mask updates

Testing

• python -m pytest tests/hermes_cli/test_cmd_update.py tests/hermes_cli/test_update_check.py tests/hermes_cli/test_update_git.py -q
  • 15 passed

Notes

This fixes the false-positive "Already up to date" behavior in fork-based Hermes development checkouts while preserving existing behavior for normal installs where main tracks origin/main.