fix(updater): let RC users upgrade to newer RC *and* stable releases

[nwparker]

Summary

Follow-up to #1053. That PR fixed the RC→RC case by switching prerelease users to electron-updater's native github provider with allowPrerelease=true — but it silently broke RC→stable:

• GitHubProvider.getLatestVersion() filters the atom feed by channel.
• When the running build's channel is `rc`, entries with `channel=null` (i.e. stable releases) fail both the `shouldFetchVersion` check (currentChannel is not in `["alpha","beta"]`) and the `isNextPreRelease` check — so they get silently skipped.
• Net effect: a user on `v1.3.19-rc.6` hitting "Check for Updates" never sees `v1.3.19` GA. They're trapped on the RC channel.

Fix

Keep the generic provider and resolve the newest tag ourselves:

1. New `updater-prerelease-feed.ts` parses `https://github.com/stablyai/orca/releases.atom\` (no channel filter) and returns the newest tag whose parsed semver is strictly greater than the running version — stable or RC, whichever is newer.
2. Before each check, if the running build is a prerelease and we haven't opted into RC via Shift-click, re-pin the generic feed at `/releases/download//`. The follow-up manifest fetch resolves against that exact release.
3. Stable users: unchanged — default `/releases/latest/download/` feed.
4. Shift-click RC opt-in (`enableIncludePrerelease`): unchanged — still uses the native github provider; resolver is skipped so it can't clobber the provider switch.

This handles both the RC→newer-RC case from #1053 and the RC→stable case it broke.

Test plan

• `pnpm run typecheck` clean
• `pnpm run lint` clean (0 errors)
• New unit tests in `updater-prerelease-feed.test.ts` (7 cases):
  • RC on current, newer stable in feed → picks stable
  • RC on current, only newer RC in feed → picks newest RC
  • nothing newer in feed → null
  • unparseable tags ignored
  • atom fetch not-ok / throws → null
  • picks semver-newest across a non-chronologically-sorted feed
• Updated `updater.test.ts` (5 cases) — replaces the PR fix(updater): keep prerelease users on the RC channel #1053 setup-time assertions with per-check resolver behavior:
  • RC user → feed re-pinned to newer RC tag
  • RC user → feed re-pinned to newer stable tag (the bug this PR fixes)
  • Resolver returns null → fallback to `/releases/latest/download`
  • Stable user → resolver never called
  • Post Shift-click opt-in → resolver never called (github provider preserved)
• Full `src/main` updater suite: 73 tests passing
• Unrelated failures in `local-pty-provider.test.ts` / `terminal-attribution.test.ts` are also present on `main` — confirmed by stashing this diff.

Notes

• Can't be exercised via `/electron` locally: the updater only activates on `app.isPackaged && !is.dev`. Logic is covered by the unit tests above; empirical verification will happen once an RC is cut with this change.

Made with Orca 🐋