fix(dispatch): make SSH CLI install work and return snapshot results

[bobleer]

Preparing an SSH dispatch target failed for every host, and a finished snapshot job had no way to give its work back.

Every fresh install failed, with an unreadable error

bitfun-cli is a shim that resolves the real binary as its own sibling via current_exe(). The installer staged the pair under dotfile temp names in ~/.local/bin, then smoke-tested the shim before committing — at which point no file named bitfun existed yet. The shim exited 1 and the install rolled back with staged bitfun-cli companion did not run, and the check discarded stderr, so the one actionable line never surfaced.

Staging now happens in a private subdirectory under the real filenames: sibling resolution holds, the commit stays a same-filesystem atomic rename, and both companion checks report the loader's own message.

This also closes a silent hole. On an upgrade the old check "passed" by exec'ing the previous binary, so it never validated the new one at all.

A build without dispatch installed as if it had worked

This installer exists only to serve dispatch, so dispatch --help is verified before anything is replaced. Without that gate, installing a release predating the feature succeeds, the target is then reported incompatible, and the user reinstalls forever.

For the same reason, a target already running the release version is no longer offered that install. The message carries the probe's own error, so a genuinely feature-less release is distinguishable from a transient failure.

Note: no published release currently contains dispatch — v0.2.14 predates it (git ls-tree v0.2.14 has zero files under src/apps/cli/src/dispatch/). This gate makes that state report honestly instead of looping; a release carrying dispatch is still required before the prebuilt path can produce a working target.

The controller's uplink was the only path for the archive

The target now fetches the release itself when it can, falling back to the SFTP push on any failure.

A target has no minisign and no trust root, so it only ever checks a plain SHA-256. That is sound only because this machine verifies the signature over the tiny .sha256 sidecar first and hands down a proven digest — the pattern already used for relay deploys. When that sidecar is unsigned the digest is unauthenticated and the archive's own signature becomes the sole protection, so the bytes must flow through the controller: that case is refused, not downgraded.

Unsupported hosts got a flat error

Probe now reports libc family, glibc version, toolchain and free space, and names the actual reason (unsupported platform, musl, glibc below the 2.35 release floor).

A source build is offered whenever no prebuilt install can proceed, listing every missing prerequisite at once. It reuses the same staging, smoke-test and commit path so rollback semantics cannot drift, and it never installs a toolchain on someone's server.

Results were stranded on the target

The design doc says the UI names the managed path and that applying results stays a confirmed local operation. Neither existed.

The delivered manifest is persisted as a baseline, a workspace-result verb diffs the terminal tree against it, and the changed files come back as a bundle. The diff is content-addressed from the manifest's per-file digests, so it works for workspaces that are not git repositories.

Nothing is written locally until the user reviews the list. When a path moved on both sides the apply aborts and reports the conflict rather than choosing a winner; taking the target's version is a separate explicit confirmation. workspace_result_bundle is advertised as an optional capability so older targets stay usable.

The dialog had no information hierarchy

Two type sizes, no heading elements, three approval cards crushed into a 560px modal, and the consent gate coloured identically to the install action. Rebuilt with real heading levels, sectioned cards, single-column options, warning colour reserved for consent, and a pinned footer over an independently scrolling body.

Verification

Against a real Ubuntu 24.04 / glibc 2.39 target:

Check	Result
Fresh install on a bare host	succeeds; both entrypoints run
Upgrade over an existing install	atomic, both entrypoints run
Rollback on a broken archive	previous binary byte-identical, exit recorded
Target-side download of the real 35 MB release	~3s, digest verified, .part cleaned
Digest mismatch	rejected, nothing published
Dispatch-support gate vs. real v0.2.14	refused, existing install byte-identical

The snapshot → commit → result round trip was driven through the real CLI verbs, confirming the baseline manifest is persisted and the diff is correct (including that a rewrite with identical bytes is not reported as a change).

Automated: 119 services-integrations, 12 dispatch_workspace, 54 CLI, and 1318 web-ui tests. Clippy clean on all changed crates.

Known gaps

• The source build pins to the release tag, so it only yields a dispatch-capable CLI once a release carrying dispatch exists.
• The source build path itself was not executed end to end: the test host has no Rust toolchain, and installing one there was not mine to decide.