Add an update checker that notifies users when a newer release is available

Problem

Skill Recorder has no in-app awareness of its own release channel. package.json is at 0.3.0 and app.getVersion() is only used for diagnostics (electron/debug-bundle.ts, electron/recorder/controller.ts) — nothing ever compares it against what's published.

The only documented upgrade path is manual: INSTALL.md ("Updating and uninstalling") tells users to re-run the source installer with a new release's full commit SHA, and README.md repeats this. That means a user who installed once will silently stay on an old build until they happen to revisit the repo. They miss fixes and, more importantly, security updates.

Proposal

Add an update checker to the Electron main process.

Phase 1 — notify (must have)

• On app start (and optionally on a long interval, e.g. every 24h), query the GitHub Releases API for microsoft/skill-recorder to find the latest published release.
• Compare the release tag (vX.Y.Z) with app.getVersion() using semver ordering, not string equality.
• If a newer version exists, surface a non-blocking notification in the UI with the new version, a short summary/link to the release notes, and the correct upgrade instructions for how this copy was installed.
• Make it dismissible and don't re-nag for the same version.
• Add a manual "Check for updates" entry (tray menu and/or settings) so users aren't dependent on the automatic check.

Phase 2 — assisted / automatic download (nice to have, needs discussion)

Because the project has two distinct release channels (see RELEASING.md), one updater strategy will not fit both:

• Source installs (install.ps1 / install.sh, commit-pinned): auto-download is not appropriate. The installers are deliberately inspect-first and hash-verified, and RELEASING.md requires commands to pin a full 40-character commit SHA rather than a branch or mutable tag. Best case here is showing the exact copy-pasteable commit-pinned command for the new release plus the published install.ps1 / install.sh SHA-256 values.
• Binary installs (NSIS / portable / dmg from npm run dist*): these could support downloading the new artifact, but binary releases are optional, may be unsigned or ad-hoc signed, and ship with a companion compliance archive. Any download flow must verify the published SHA-256 before doing anything with the artifact, and must not bypass the compliance/asset expectations in RELEASING.md.

So: notify everywhere, and only consider real download/apply for the binary channel.

Implementation notes

• Detect the install channel at runtime (packaged vs. source-installer layout) so the update message shows the right instructions.
• The check must fail silently and never block startup or recording — no network, rate-limited, proxied, and offline environments all have to degrade gracefully.
• Respect an opt-out: an env var / setting to disable update checks entirely (useful for enterprise and CI). Document it.
• Note in the docs that the check contacts api.github.com; it should be the only network call added and should send no telemetry.
• electron-updater is the obvious off-the-shelf option, but it implies a publish provider and auto-download semantics that clash with the source-only default channel, and it adds a dependency subject to the license/compliance review in RELEASING.md. A small hand-rolled fetch against the Releases API may be the lower-risk starting point for Phase 1.
• Handle pre-release/draft releases explicitly (skip them by default).

Acceptance criteria

• Running an older version shows a clear, dismissible "update available" notification with the new version number and a link to the release.
• Running the latest version shows nothing.
• A manual "Check for updates" action exists and reports both outcomes (up to date / update available).
• Update instructions shown match how the app was installed (source vs. binary).
• Failures (offline, API error, rate limit) are logged and otherwise invisible to the user.
• Update checks can be disabled via a documented setting/env var.
• Version-comparison logic has unit tests (semver ordering, equal versions, pre-releases, malformed tags).
• INSTALL.md / README.md updated to describe the new behavior and the opt-out.

Start by tracing app.getVersion() usage in electron/debug-bundle.ts and electron/recorder/controller.ts, then review package.json, the installer layouts, and RELEASING.md. Define the Phase 1 update-check scope across source and binary installs before implementing it. Done means the acceptance criteria pass, including semver tests, dismissible notifications, manual checks, graceful failures, opt-out documentation, and updated INSTALL.md/README.md.