Dashboard: "new release available" badge linking to the GitHub release (#224)

[VijitSingh97]

Closes #224. A small, notify-only callout: a header badge that links to a newer GitHub release. Exactly what was asked — an extra badge on top, "New release vX.Y.Z available", clickable, no self-updating.

What it does

When dashboard.check_for_updates is enabled, the dashboard periodically asks GitHub for the latest release and — if it's newer than the running version (#58's PITHEAD_VERSION) — shows a badge next to the version badge:

New release v1.4.0 available ↗ → links to …/releases/tag/v1.4.0 (new tab)

It never updates anything; you upgrade with ./pithead upgrade on your own terms (the one-click upgrade is the separate #59).

Privacy (the important bit)

A dashboard→GitHub check is a new outbound egress, so per the #160 policy:

• Off by default (dashboard.check_for_updates: false) — the appliance never contacts GitHub unbidden.
• When on, the check is routed over the bridge Tor SOCKS (reuses XVB_TOR_PROXY, same pattern as the XvB fetch Dashboard: route XvB stats through Tor + gate behind XVB_ENABLED (IP↔wallet leak) #163), so enabling it can't reveal the host IP to GitHub.
• Cached (hourly), and fails silently offline / Tor-only (no error, no badge).
• Listed in docs/privacy.md's egress table + documented in docs/configuration.md.

Implementation

• service/update_checker.py — parse_semver + compute_update (pure), GitHubReleaseClient (Tor fetch, fail-silent), UpdateChecker (hourly throttle; keeps the last result through a transient blip so the badge doesn't flicker).
• data_service runs it in the existing poll loop (gated on the flag, throttled, asyncio.to_thread) → latest_data["update"]; build_state surfaces state.update; components.mjs renders the UpdateBadge in the Header.
• Config: dashboard.check_for_updates (default false) → DASHBOARD_CHECK_UPDATES via pithead + compose; describe_change names GitHub/Tor.

Tests + validation

• 17 dashboard tests (SemVer parse, compute_update ordering, client fail-silent paths, throttle, build_state surfacing) — update_checker.py 100% covered; 5 shell tests (default-off render, opt-in propagation, describe_change).
• Verified end-to-end in a real browser: the badge reads "New release v1.4.0 available ↗", links to the release, opens in a new tab, accent styling.
• Full suite green; dashboard coverage 94%; lint clean.

Independent of #223 (the #44 pull-install) — they touch adjacent code but separate concerns; this branch is off main and stands alone.

🤖 Generated with Claude Code

[VijitSingh97]

Update (follow-up commit): flipped to default-on + a stack-wide egress audit.

• dashboard.check_for_updates now defaults to true. Since the check is Tor-routed (socks5h — neither the host IP nor a DNS lookup reaches GitHub; it only ever sees a Tor exit), there's no privacy leak, so it's safe to default on. Set false to opt out.
• Stack-wide egress audit reconciled into docs/privacy.md + a comment on the [Epic] Privacy: no clearnet egress outside Tor — close leaks + privacy-first defaults #160 epic:
  • No new runtime clearnet leaks. The only on-by-default clearnet runtime egress remains p2pool: route outbound sidechain P2P through Tor by default (--socks5), documented clearnet opt-out #165 (p2pool outbound) + XvB donation: route mining upstream through Tor by default + pin --donate-level 0 (xvb.tor opt-out) #166 (XvB donation) — already v1.1 (need benchmarking).
  • Documented the one gap found: the GHCR image pull Release & versioning structure (single-product releases via GHCR) #44 introduced (ghcr.io/.../pithead-* on a release install/upgrade) — an inherent build/setup egress, now in privacy.md's build/setup table.
  • monerod/Tari DNS stay closed/sinkholed; monerod-RPC-to-remote is clearnet only in the opt-in monero.mode: remote path; pithead itself makes no egress.
• Docs holistic: configuration.md, privacy.md, dashboard.md (badge note), CHANGELOG. Tests: shell render now asserts default-on + the opt-out path.

CI 12/12 green.