Add update notifications for the prebuilt Windows binary Problem

Problem

A candidate running the prebuilt Windows binary from the latest release has no way to know that a newer build is available.

Every successful build of main can replace the latest release, but an already downloaded Windows executable continues running the version it was built from. Since the package version remains 0.1.0 across builds, users cannot rely on the package version alone to determine whether their binary is up to date.

Currently, a candidate must manually visit the GitHub Releases page and compare the commit reported by the running binary with the commit associated with the latest release. In practice, this check is easy to overlook.

As a result, Windows users may continue practicing with outdated builds that are missing bug fixes or improvements already available in newer builds. This can also make bug reports more difficult to investigate when the reported behavior no longer matches the latest version.

The existing macOS update notification issue addresses the same problem for macOS users. Windows users should have equivalent functionality for their prebuilt binary.

Proposed behavior

The Windows binary should check whether the latest release identifies a different commit from the running binary at the following moments:

1. When the binary starts and the lobby first loads.
2. When the candidate ends an interview and returns to the lobby.
3. Every hour on the hour while the lobby remains open and no interview is running.

When a newer build is available, the lobby displays a dialog containing:

• The commit of the currently running binary.
• The commit associated with the latest release.
• A working link to the latest release page or the appropriate Windows download asset.

The notification is informational only. The candidate remains responsible for downloading and replacing the executable manually.

No update check should run, and no notification should appear, while an interview is in progress.

If the running binary already matches the latest release, no notification should be displayed.

Scope

This issue covers the prebuilt Windows CLI binary distributed through the latest release:

codetrial-x86_64-pc-windows-msvc.exe

The implementation should reuse the update-checking mechanism introduced for macOS wherever possible. Windows support should not require a separate update service or duplicate the release-checking logic.

The Windows implementation should account for the following:

• Platform-appropriate download link: The notification must not direct Windows users to a macOS-specific archive or executable. Linking to the latest release page is acceptable if a reliable Windows-specific asset URL is not available.
• Manual updates only: Automatically downloading, installing, or replacing the executable is out of scope.
• Configuration preservation: The update instructions should remind users to preserve their existing config/ directory when replacing the executable.
• Release builds: The check should follow the shared implementation's policy for distinguishing official release binaries from builds compiled from source.
• Failure isolation: Update-check failures must not prevent the application from starting or interfere with an active interview.

Linux binaries and the desktop application's desktop-latest release are outside the scope of this issue.

Acceptance criteria

• A Windows binary whose embedded commit differs from the latest release displays an update notification with the running commit, the latest commit, and a working link to the release page.
• A Windows binary that matches the latest release displays no notification.
• If the update check fails, the notification is not displayed, and CodeTrial continues to work normally.
• No update check runs and no notification appears while an interview is in progress.

Implementation notes

The existing build process embeds the first seven characters of GITHUB_SHA as CODETRIAL_BUILD_COMMIT. The release workflow associates the latest release with the commit used to build the release.

These values can be compared directly to determine whether a newer build is available. The package version alone is insufficient because it remains unchanged across builds.

The preferred approach is to reuse the server-side update-checking mechanism proposed in #543:

1. The server queries GET /repos/sysprog21/codetrial/releases/tags/latest on the GitHub API.
2. The server caches the release information.
3. The lobby retrieves the latest commit and release URL through a server endpoint.
4. The lobby compares the latest commit with CODETRIAL_BUILD_COMMIT and displays the notification only when they differ.

Reusing this mechanism avoids unnecessary GitHub API requests from individual tabs and avoids adding GitHub's API origin to the page's connect-src policy.

The implementation should follow the shared policy for builds compiled from source that do not correspond to an official release.

Update-check failures must be handled gracefully and must not affect the normal operation of CodeTrial.

Related

#543 — Tell macOS binary users when a newer release is available
#153 — Report the build commit
#14 — Introduce the rolling latest release
Installation documentation