Show in-cluster Radar upgrade status

[nadaverell]

Summary

Shows standalone in-cluster operators which Radar version is running, whether a newer release is available, and the correct place to make the upgrade. Verified Helm and GitOps ownership links directly to the managing object; uncertain ownership falls back to safe installation-specific guidance.

What changed

In-cluster upgrade experience

• Adds the running Radar version and available release to the Home cluster summary, with quiet treatment for patch releases and stronger emphasis as installations fall further behind.
• Links verified Helm releases, Argo CD Applications, Flux HelmReleases, and Flux Kustomizations to their existing Radar views. Suspected, unreadable, ambiguous, and unknown ownership routes to the in-cluster upgrade guide.
• Removes the floating local-style update prompt from shared in-cluster and Cloud deployments. Local and Desktop behavior is unchanged.
• Expands the in-cluster guide with Helm, Argo CD, Flux, verification, rollback, ingress-authentication, and uninstall guidance.

Version checks

• Keeps release data behind the existing backend update check and one-hour cache, with concurrent cache misses coalesced and Cloud release-only lookups isolated from the default path.
• Allows standalone in-cluster browser profiles to request one additional same-origin update check per API base and UTC day after a successful version lookup. The request is best-effort and is not retried.
• Classifies stable, prerelease, custom, and development build shapes consistently. Development builds use the release-only path and do not use the daily relay.
• Includes the installation timestamp when it can be determined, preferring the Deployment creation time and retaining the local Radar directory fallback.

Testing

• make test
• make build (includes frontend type-check and production build)
• Focused frontend version, update-notification, daily-check, and upgrade-link tests: 4 files / 26 tests
• Frontend CI: full suite passed
• Visual test skipped: the upgrade states depend on published-version and ownership responses that the local development build does not produce; the rendered states are covered by component tests

Deployment note

Deploy the paired receiver change before releasing this Radar change: https://github.com/skyhook-dev/marketing/pull/284

---

Note

Medium Risk
Changes outbound update telemetry (browser relay, install timestamp, channel/source params) and version-check caching paths used at startup and in Cloud mode; UI routing depends on ownership detection being correct to avoid misleading upgrade CTAs.

Overview
In-cluster operators now see the running Radar version on the Home cluster summary, with tiered emphasis when a newer release exists (patch vs minor vs stale/major). Verified Helm or GitOps ownership can deep-link into the Helm release or managing Argo/Flux object; uncertain ownership falls back to the in-cluster upgrade docs instead of GitHub release notes.

The floating Update Available popup is suppressed for in-cluster and Cloud deployments (local/desktop unchanged). Settings upgrade links route in-cluster users to the same docs.

Backend version checks are reworked: per-source caching with single-flight coalescing, build channel and source query params on releases.skyhook.io, CheckForUpdateRelease for Cloud and dev-shaped builds, and IsReleaseVersion (semver) replacing ad-hoc regex in the explorer reachability path. A new POST /api/version-check/browser lets the UI relay one extra telemetry check per API base and UTC day after a successful version lookup (in-cluster only; dev builds skip relay).

Cloud connect self exposes controllerRef for verified GitOps so the UI can navigate without guessing. Docs expand Upgrading (Helm, GitOps, verification/rollback) and tighten ingress auth guidance. Makefile VERSION uses git describe with v* tags only.

^{Reviewed by Cursor Bugbot for commit dcb8c29. Bugbot is set up for automated code reviews on this repo. Configure here.}