fix: preserve shallow clone boundary on update fetches

[bydbot]

Summary

Shallow installs (git clone --depth 1) get silently unshallowed by update fetches, dragging in the entire repository history (hundreds of MB).

Two call sites run a plain git fetch on the checkout:

1. Desktop auto-update check — checkUpdates() in apps/desktop/electron/main.ts runs git fetch --quiet origin main every ~10-30 minutes while the app is open. On a shallow clone a bare fetch cancels the shallow boundary and transfers the full history. Measured impact on a real installer checkout: .git grew from ~20MB to 591MB (a 337MB full-history pack, plus a 200MB orphaned tmp_pack_* from an interrupted fetch).
2. hermes update — _cmd_update_impl() in hermes_cli/update_cmd.py runs git fetch origin <branch> with no depth guard.

The CLI update-check path (update_cmd.py check + banner.py) already detects shallow repos and fetches with --depth 1 to preserve the boundary — this PR aligns the two remaining call sites with that guard.

Changes

• apps/desktop/electron/main.ts: in checkUpdates(), probe --is-shallow-repository before fetching and pass --depth 1 when shallow (mirrors banner.py). The existing --is-shallow-repository / merge-base logic further down already handles the shallow case for the behind-count.
• hermes_cli/update_cmd.py: in _cmd_update_impl(), reuse the same shallow probe + depth_args pattern already used by the update-check path.

Verification

• Local bundle-electron-main.mjs build passes; bundled electron-main.mjs contains the --depth 1 fetch branch.
• python -m py_compile hermes_cli/update_cmd.py passes.
• Behavior unchanged for full clones (no --depth added when not shallow).

[teknium1]

Thanks @bydbot — closing as wrong-premise/superseded after verification. A branch-scoped git fetch origin <branch> on a shallow repo does not unshallow it (the shallow boundary is preserved; verified empirically in #84597's investigation as well), so the "drags in hundreds of MB" failure mode doesn't occur at these call sites. The related count problems are fixed on main: desktop update checks use shallow detection + GitHub compare API recovery (PR #86257), and the CLI apply-path count is fixed by PR #86318. Appreciate the report — the symptom cluster was real even though the mechanism was elsewhere.