fix(dashboard): GitHub releases fallback for Update Available banner (#4100)

[diegosouzapw]

Closes #4100 (re-opened after the v3.8.28 fix).

Why still broken

The v3.8.28 fix added an npm-registry HTTP fallback to resolveLatestVersion(). But on networks that reach GitHub (where the dashboard news feed already loads via getNews()) yet block registry.npmjs.org + have no npm binary (Docker/desktop/locked-down), both existing sources still return null → updateAvailable=false → banner silently hidden. This is the surviving cause reported by @csoxiza.

Verified from a clean internet host: npm CLI, registry.npmjs.org/omniroute/latest and api.github.com/.../releases/latest all return 3.8.39 — so the logic is correct when a source is reachable; the gap is source reachability.

Fix

resolveLatestVersion() now tries npm CLI → npm registry → GitHub releases before giving up (the GitHub source the issue itself suggested), and warns only when all three fail. New getLatestVersionFromGitHub() reads the latest release tag_name (v-prefix tolerated by normalizeVersion).

Tests

tests/unit/system-version-check-4100.test.ts (12/12): GitHub fallback engaged only after npm CLI + registry fail; registry short-circuits before GitHub; tag_name parsing; non-OK → null; all-fail → null. Fail-before: the GitHub export/param did not exist on the prior module.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.