fix(desktop): never show bogus commit-behind count on shallow clones

[Bors6656]

Summary

A shallow hermes-agent checkout that shares a merge-base with origin/main still runs git rev-list HEAD..origin/<branch> --count in checkUpdates(), and surfaces the raw (real but alarming) commit distance in the desktop update pill — e.g. 4650 commits behind on a shallow pin that simply hadn't been updated.

apps/desktop/electron/update-count.ts only skipped the count when isShallow && !hasMergeBase. The shallow-with-merge-base case fell through to the count and produced the bogus large number.

This aligns the desktop with the already-correct CLI guard in hermes_cli/banner.py: any shallow checkout skips the count and falls back to a tip-SHA compare, showing a generic "update available" instead of a scary, unactionable number. Full clones keep the exact-count path unchanged.

• shouldCountCommits → return !isShallow
• resolveBehindCount → binary SHA compare when isShallow, else the parsed count

Test plan

• Updated update-count.test.ts: it previously asserted the buggy shallow+merge-base behavior (count kept); now asserts shallow always resolves via SHA compare. Added the missing shallow+merge-base case that produced the 4650.
• vitest run electron/update-count.test.ts → 11/11 pass.
• tsc -p apps/desktop/tsconfig.electron.json --noEmit → clean.

Root cause reference

First reported as the desktop update pill showing "4650 updates" on a shallow install. Mirrors desktop note in banner.py (shallow clones compare tip SHAs, never count).

🤖 Generated with Claude Code

[teknium1]

Closing — superseded by PR #86257 (merged, bf10349), which lands the same behavioral change your PR argued for: shallow checkouts never trust rev-list --count, with or without a merge-base (your "shallow + merge-base = live bug 4650" case included, backed by a real-git fixture test from #64469). #86257 goes one step further than presence-only: it recovers the exact count via the GitHub compare API when reachable. Your PR arrived after #64469 (Jul 14) made the same always-skip argument, so credit for the base went to the earliest submitters (#61050/#83381/#64469) — but thanks for the clear analysis and the real-world 4650 datapoint, which is cited in the merged test comments.