UI: add an explicit update check and source-aware command handoff

[rarepops]

What problem does this solve?

The browser UI can show the serving binary version (#1820), but users still need to leave the UI and determine how that installation should be updated. The correct command depends on ownership: a native install hands off to the verified install.sh or install.ps1 beside the binary, while package-manager-owned installs must remain under their package manager.

The project intentionally performs no background release check. Any UI workflow must preserve that privacy boundary and must not turn page load into an outbound request.

Proposed solution

Add an Updates section to the Control tab with a staged, non-executing workflow:

1. Show the current serving version from UI: show the serving binary version in the header #1820.
2. Provide an explicit Check for updates action. Only that user action may ask a same-origin backend endpoint to perform a fixed-destination release check.
3. Return structured current/latest/update-available state and a source-aware handoff command derived from the same ownership logic as cbm_cmd_update.
4. Let the user copy the exact command. Do not execute it from the browser in this phase.
5. Report network/unavailable and unsupported-install-source states without changing the running daemon.

Security and behavior constraints:

• no automatic or background network request
• no user-controlled URL, executable, path, or shell fragment
• retain the UI's same-origin/Host checks and connect-src 'self' CSP
• native installs point only to the installer already verified and placed beside the active binary
• externally managed installs remain package-manager owned
• endpoint and UI states receive focused offline tests

A true one-click update should be a separate follow-up design. It must solve detached installer execution, daemon/UI shutdown, browser reconnection, activation status, package-manager ownership, Windows executable replacement, and explicit security review.

Alternatives considered

• Background update checks: rejected because the product deliberately makes no unsolicited network request.
• Browser-to-GitHub requests: rejected because the UI CSP intentionally blocks external connections and the backend should own any explicit release lookup.
• Run the installer immediately from the new endpoint: deferred because it turns a read-only UI workflow into a privileged download/execute/restart path and the serving daemon disappears during activation.

Confirmations

• I searched existing issues and pull requests and this is not a duplicate.