release: v0.4.12 — add kuri update, and actually install kuri-mobile

[justrach]

Hotfix

Two problems that made the installed product differ from the built one.

install.sh never installed kuri-mobile

BINS="kuri kuri-agent kuri-fetch kuri-browse"   # ← no kuri-mobile

kuri-mobile has been inside the release tarball since 0.4.6. It was built, packaged, shipped — and then dropped on the floor at install time. Because kuri android and kuri ios exec it as a sibling binary:

// build.zig
// `kuri` execs this as a sibling binary, so it has to land in the same
// install prefix — and therefore the same release tarball.

…every install since 0.4.6 produced a kuri whose mobile subcommands fail with failed to exec 'kuri-mobile', after an install that reported success. Four releases of mobile work were undeliverable through the documented install path.

Caught by trying to answer "how do I update kuri" and reading the installer instead of assuming it worked.

kuri update did not exist

$ kuri update
error: unknown argument 'update'

Upgrading meant remembering an installer URL and piping it to a shell. Now:

$ kuri update --check
kuri 0.4.11 (aarch64-macos)
already up to date (v0.4.11)

• --check reports what would happen and changes nothing
• --dir=<path> overrides the destination. By default it installs next to the running binary, so an update replaces this install rather than creating a second one that may or may not win on PATH
• upgrade is accepted as an alias — failing an upgrade command over vocabulary is a poor way to meet someone trying to get onto a newer version

Two implementation choices that are the point of doing this in the binary rather than in shell:

The SHA-256 is verified in process. install.sh tries shasum, then sha256sum, then openssl, and if none is present it skips verification entirely and installs anyway. A verification step that depends on which of three tools happens to be on PATH is a verification step that can quietly not happen.

Binaries are installed by rename, not cp. Copying onto a running executable fails with ETXTBSY on Linux and can corrupt a concurrently-executing image elsewhere. The staged file is written into the destination directory, since rename cannot cross filesystems and /tmp frequently is one.

curl is used purely as transport, deliberately — routing this through the in-tree TLS stack would let a TLS regression break the one command meant to repair it.

Verified

Check	Result
zig build test (root)	298 passed
zig build test (kuri-mobile)	42 passed
zig build e2e-ios	54 passed, 0 failed
kuri update --check against the live channel	correctly reports up-to-date
kuri update --bogus	rejected, exit 1

New unit tests cover manifest parsing (valid, missing-platform, malformed-JSON), the SHA-256 helper against a known digest, and the v-prefix handling that the version comparison depends on.

The upgrade path itself gets a real end-to-end test once this publishes: a stashed 0.4.11 binary runs kuri update against the live channel and must land on 0.4.12.

🤖 Generated with Claude Code

https://claude.ai/code/session_012gzdKWXk7UbHm5TtSGqYBJ