feat(cli): add atomic-agent update self-update command

[yablokolabs]

Summary

The TUI offers an in-app self-update (startup check → update_available prompt → re-run install.sh in place → restart handoff), but headless / run / serve / sidecar users never see it — there is no CLI surface for updating the installed binary.

This adds a first-class atomic-agent update command that reuses the existing src/update/ module unchanged:

• atomic-agent update — checks GitHub Releases; confirms interactively when attached to a TTY; re-runs the canonical installer in place when a newer version exists
• atomic-agent update --check — probe only, reports current vs latest, exits 0 whenever the check itself succeeds
• atomic-agent update --version <tag> — installs a pinned release tag (still refuses dev builds, still confirms interactively)
• Follows the documented CLI exit-code contract: 0 success, 1 operational failure, 2 usage error
• Refuses to self-update under node/tsx dev runtimes (matches canSelfUpdate semantics); the running process is not restarted — the next launch picks up the new binary (installer already swaps atomically)

Files

• src/cli/update-command.ts — new command (+ injectable deps seam for tests)
• src/cli/update-command.test.ts — 15 tests (help, usage errors, --check, dev-build refusal, in-place update, streaming lines, interactive confirm/cancel, pinned version)
• src/cli/index.ts — register update in COMMANDS + help
• README.md — document the command next to the existing update notes

Test Plan

• npm run lint (tsc noEmit) passes
• npx vitest run src/cli/update-command.test.ts — 15/15 pass
• npx vitest run src/cli/ src/update/ — 112/112 pass
• npm run build + node dist/cli/index.js update --help smoke test
• Full suite: 4893+ passed; the only failures are two pre-existing flaky tests (send-message-concurrency, llm-health-poller) that also fail on pristine main (verified separately) — untouched by this change

[plombeer31]

Reviewed while integrating this into the 0.3.3 build — it's in, and the command works. One finding worth a follow-up.

src/cli/update-command.ts:178 — a non-TTY update replaces the binary with no confirmation.

The confirm prompt is gated on isTTY(), and there's no --yes flag, so any non-interactive invocation performs an unattended in-place binary swap:

# cron, CI, or just piping the output
atomic-agent update | tee update.log

isTTY() is false, the confirm branch is skipped entirely, and runAppUpdate re-runs the installer against the live install directory — swapping the binary under any other running instance without anyone approving it. The help text advertises --check for a dry run but never says that a non-TTY run auto-confirms.

Two ways out, either is fine: refuse in non-TTY unless --yes is passed, or keep the behaviour and document it in HELP next to --check.

Nothing else came up: the flag parsing, the pinned-tag path and the exit codes all read correctly, and the dependency seam makes it testable without touching the network.

[yablokolabs]

Follow-up addressing the non-TTY auto-confirm finding: #213

Adds --yes / -y flag. Non-TTY invocations without it now refuse with exit 1. TTY invocations still prompt as before. 7 new tests, 21 total.