[gbradham]

Why

The updater only looked at GitHub Releases, and the latest is still v1.0.0, so a checkout many commits behind main was told it was up to date. We ship from main rather than from tags.

What

• Git checkout (what both installers make): at launch, GitHub's compare API reports how far main is ahead of the local HEAD. If it's ahead, the dialog says "N new changes on main since your copy", lists the newest commit titles, and offers Update now, which runs git pull --ff-only origin main.
• If the pull can't fast-forward (local commits or a diverged branch), it refuses and shows git's error. The checkout is never left half-merged.
• A pull that changes pyproject.toml or uv.lock tells the user to re-run the installer. It doesn't reinstall dependencies itself, because the installer's extras aren't recorded.
• Prebuilt app (no .git): still checks Releases, as before.
• A HEAD that GitHub doesn't know (an unpushed commit) gets a 404 from the compare API, so the check stays quiet.

Testing

• New tests cover the compare parsing, the checkout/prebuilt dispatch, and pull_main against a local throwaway origin (fast-forward, dependency flag, refusing a diverged checkout).
• test_updater.py and test_first_run.py pass (50 tests); ruff and black are clean.
• Checked against the live API: a checkout at current main reports 0 behind, and e5fac47 reports 31 behind with the correct commit list.