Identify rolling releases and show rolling updates in Settings

[FlintSH]

What does your PR do?

Settings identifies a rolling build with a compact version, channel, and source-commit line. A short warning explains that it is a pre-release and may be unstable or break. The version area automatically checks for newer rolling releases and offers compact inline links to the release and incoming commit when an update is available, with a quiet manual refresh control.

Why are you making these changes?

Rolling images currently show only the package version and check for stable releases, so users cannot identify their build or tell whether a newer rolling image exists.

How did you implement it?

• Bake the rolling channel and full source commit into both Docker architectures, then pass runtime build information to Settings.
• Compare the installed commit with the published rolling release's recorded commit. Keep current, newer, ahead, unknown, and failed checks distinct; stable builds continue checking stable versions.
• Assemble manifests from commit-specific images and serialize rolling publication. Update release metadata successfully before advancing the rolling Git tag, so a failed metadata write does not move the public tag. Stable release notes ignore the moving rolling tag.
• Add 30 backend tests covering build metadata, channel selection, comparisons, missing metadata, GitHub failures, and administrator authorization, plus four rendered-component regression tests for installed/incoming commit links and stable release behavior.

Screenshots / Recordings (if UI)

Desktop and mobile, with a mocked available-update response:

Related Issues

No linked issue.

Additional Info

Validation:

• Full unit suite: 403 passed; 56 database-dependent tests skipped.
• TypeScript, lint, and changed-file formatting checks passed.
• Browser checks covered installed-commit, incoming-commit, and release links, automatic and manual checks, loading/current/unknown/error/retry states, dark/light themes, and 1440/390/320px widths without overflow or page errors.
• Five mocked executions of the actual release workflow covered successful and failed metadata updates for existing/first releases, plus a tag-push failure. Metadata-update failures never reach the explicit Git tag push.

The previous CI run passed both architecture Docker builds and Code Quality. Meticulous built and smoke-tested the container, but could not create a test run because the project's cloud test quota was reached: CI log. No visual diffs were produced by that run.

Official rolling builds gain metadata through the updated workflow; README documents the arguments for custom builds.

[github-actions]

Flare PR preview: closed

Preview and disposable data removed.

Commit: e40e914c84eb

Public, disposable test instance running untrusted PR code. Anyone can view or change its test data. Do not enter passwords you use elsewhere, credentials, or private files.

[greptile-apps]

Greptile Summary

This PR improves rolling-build update visibility and release consistency. Rolling release metadata is published before the public rolling tag advances, and the Settings page now exposes the exact commit available in a rolling update.

Confidence Score: 5/5

Safe to merge; no outstanding blocking issues remain.

The rolling metadata consistency issue is fixed: the workflow updates or creates the rolling release, including its commit marker, before force-moving the public rolling tag. The incoming rolling commit visibility issue is fixed: the Settings UI now renders a link to the available commit when the update response provides its SHA and URL. Both threads were resolved without an explanatory reply; greptile-apps[bot] resolved them without explanation.

_{Reviews (4): Last reviewed commit: "Assert rendered link content without str..." | Re-trigger Greptile}