[Feature]: Route t3 update and desktop updates through one coordinated update flow

[Trahloc]

Problem

T3 exposes several update entry points, but they do not converge on the same coordinated update flow.

In stable 0.1.7:

• The desktop sidebar's "Update everything" coordinates provider/server updates and then the local desktop app.
• Settings → About can call the local desktop download/install path directly ([Bug]: Settings › About › Install updates only the desktop app; the background service it is paired with stays on the old version #31506; proposed fix fix(web): Settings › About updates connected servers with the app #31559).
• t3 update uses the standalone runtime/background-service update path; when invoked through the desktop-bundled CLI, it does not delegate to the desktop's coordinated flow or replace the AppImage.
• Other native entry points should have the same clearly defined boundary: checking/downloading can remain read-only/preparation, but committing an update must use the coordinator.

This makes the update result depend on where the user started it. A successful desktop/server update can also leave a CLI launcher behind (#14609, #25724, #31507). Those are related reports, but this request is specifically about sharing the coordinated entry point, not replacing their focused fixes.

Requested behavior

For a desktop installation, t3 update, the sidebar update action, Settings → About, and native desktop update actions should enter the same T3-owned coordinated flow, with the same target selection, authorization, confirmation, in-progress exclusion, error reporting, and restart behavior.

Headless standalone installations must retain their supported CLI/service updates. Low-level download/install executors can stay platform-specific; the user entry points should not independently decide which components to skip.

A shell command must not report the desktop updated merely because a standalone archive was downloaded.

Proposed minimal solution

1. Reuse/extract the existing coordinated update request boundary rather than add a second update algorithm.
2. Route a desktop-bundled t3 update request through the existing local desktop control transport to that boundary. If the desktop is unavailable or cannot support the request, return a clear actionable error instead of silently switching update models.
3. Route the remaining desktop user entry points through that same boundary, keeping the existing native updater and server self-update machinery as executors.
4. Provide a small versioned, machine-readable, read-only capability/check result so external maintenance hooks can tell "coordinated updater supported" from "legacy or unknown" without inspecting private bundles or performing an update.

The implementation patch will follow as code and focused regression evidence. This is a proposal for maintainer review; I am not claiming prior maintainer approval.

Acceptance

• Regression coverage shows the desktop CLI and desktop UI requests reach the same coordinator, and a declined/cancelled request does not update anything.
• Concurrent entry points cannot start overlapping update runs.
• Exact-version/channel options are either preserved or explicitly refused before mutation; no silent option loss.
• Standalone/headless behavior remains supported.
• The check path performs no download, installation, restart, or launcher rewrite.
• Missing/old desktop versions are distinguishable from successful coordination.
• Hooks can inspect the check result and notify; T3 alone owns updating.

External integration

An Omarchy post-update hook is only a consumer of the supported check/request interface. It should not implement downloads, replace AppImages, patch T3, or infer that a fix is installed merely because an issue or PR closed.

Related: #31506, #31559, #14609, #25724, #25727, #31507, #31522.

Filed at the user's request after reviewing the installed 0.1.7 behavior and current source. Research/implementation assistance: GPT-6.1 Sol through Codex.

[Trahloc]

Upstream PR: #32495 — coordinate CLI and desktop updates, revised and independently reviewed at a42ae4a0afab372ba8533280639d68a86fa551ff. Current verification evidence includes an update/restart recording, report, sanitized receipt, screenshots, source manifest and checksums. Earlier evidence remains a historical record of the original submission.

The desktop-installed CLI, deprecated service alias, About, sidebar and native menu use the existing coordinated runner. Providers update first, managed servers hand off next, and the desktop installs and restarts last. Native executors retain their responsibilities. Standalone/headless updates and startup recovery keep their scoped paths; the Omarchy checker remains a separate read-only consumer.

Review identified an unsafe renderer-replacement interval. The revision keeps a started run reserved independently of renderer identity and local updater activity. Only terminal token-checked cleanup releases it. Confirmation timeout/cancellation cannot release an accepted run, and unexpected branch failures wait for all started branches. A genuinely lost document fails closed: users must check affected machines before restarting and retrying, because a desktop restart does not prove remote completion. Remote prepare and commit can wait for a native background check while retaining exclusion from other coordinated runs.

The coordinator remains mounted during onboarding and authentication gates. Before renderer readiness, the native menu can check this desktop under a reservation. Expired confirmations show feedback and start no update. The cached CLI capability check remains read-only. Transport diagnostics distinguish unavailable, actionable failures and uncertain outcomes without falling back to a standalone installation.

Verification at this head: all changed-file checks passed, including 36 affected package typechecks, 172 tests in 19 files and 8 React Compiler checks. The final Linux x64 packaged fleet run passed provider maintenance, native server commit, desktop installation last, original-main exit by pidfd, automatic relaunch into the exact final-source artifact, and saved-credential reconnection. SQLite checks independently verified all original fixture messages. The unchanged bounded checker passed twice; the report also records an earlier inconclusive run. Packaged gated-route checks displayed and cancelled the real confirmation on onboarding and controlled authentication-failure screens.

These were private runtime fixtures with no live userdata or desktop sockets mounted, local feeds and synthetic release/provider versions. The report identifies the earlier starting-image source, exact final target source and unchanged gated-route components. No production signing/distribution, macOS/Windows, vendor API calls, paid turns or systemd/SSH registration was tested. The evidence release contains no installable build or userdata.

Explicit maintainer approval of direction and scope remains unrecorded; the PR seeks that decision and does not claim an exemption. AI-assisted implementation and verification: GPT-6.1 Sol and Terra through Codex. Independent final source/evidence review: Claude Opus 5.5 high, PASS after two rounds at a42ae4a. Latest wording-only follow-up eae7e2889405a598f962f0c979bee42d4ecc3168 removes a duplicate service-install sentence. Its changed-file checks passed, including four tests; it uses the trivial-edit exemption from another independent review. Published packaged evidence remains bound to a42ae4a.