The in-app updater ran `git fetch origin main && git reset --hard
origin/main` regardless of which version the GitHub releases API
reported as latest. So whenever the latest release lived on a branch
other than main — e.g. during a beta cycle when 0.2.4b1 sits on its
own branch and main still points at the previous stable — clicking
Apply Update appeared to succeed but the user actually stayed pinned
to old main HEAD.
Fix: extract `_discover_target_release(db)` mirroring the same
release-API + include_beta_updates selection the GUI's update-check
already uses, pass the resolved tag (e.g. `v0.2.4b1`) into
`_perform_update(target_ref)`, and run `git fetch --prune --tags
origin && git reset --hard <target_ref>`. The fetch now pulls --tags
so a tag ref is locally resolvable; the reset takes the caller's
ref instead of a hardcoded branch. apply_update now returns a clear
error if no release resolves, instead of silently kicking off an
update that can't land.
maziggy
68c4a5b839