ci(release): automated tag-consistent releases + version-aware updates

[nickroci]

Problem

Two related pains:

1. Cutting a release means hand-editing the version in 6 files (5 workspace pyproject.tomls + plugin.json) and keeping the install-spec tags in sync. Error-prone.
2. scripts/ensure-ultan.sh was install-if-missing only — once bin/ultan existed it never updated, so a new release on main/@tag was never picked up. And the install used uv tool install --force, which recreates the 977 MB torch venv every time.

Approach

Releases flow from a single input (the version), and the version edits always land in the commit the tag points at — required because plugin.json's install spec is a static literal Claude Code reads as-is, so it must self-reference the very tag being cut. Since main is protected, that means edit → PR → merge → tag:

• scripts/set-version.sh <X.Y.Z> — one command rewrites every workspace pyproject version, the plugin.json version, and the @<ref> install spec in plugin.json and ensure-ultan.sh → @vX.Y.Z. Reusable in CI and locally. (Verified end-to-end: a 0.3.0 run touches exactly the 7 version/spec strings and stays coherent.)
• .github/workflows/release.yml — workflow_dispatch(version) → runs set-version.sh → opens a release/vX.Y.Z PR for review.
• .github/workflows/release-tag.yml — on that PR's merge, tags the merge commit and publishes a GitHub Release. The tagged commit already carries matching versions + @vX.Y.Z specs, so installing the tag is always self-consistent.
• scripts/check-version-coherence.sh + a ci.yml job (wired into the ci-success gate) — fails any PR where the package versions or the two install-spec refs drift apart. @main is accepted as the unreleased/dev state.

Client-side updates (the original ask)

ensure-ultan.sh now compares the installed git ref (from the uv receipt) against the SPEC's target ref. When stale, it runs an incremental uv tool install (no --force) — uv swaps only the changed packages and reuses the existing venv + warm cache (seconds, not a multi-minute reinstall). --force is kept only for a fresh or broken install. Empirically confirmed: a changed spec without --force updates in place from cache (Installed 1 package).

Workspace members are pinned by { workspace = true } (no ==), so the lockstep version bump is also the cache-correctness mechanism — a new tag → new version → fresh wheel, never a stale cached daemon.

Baseline in this PR

• Aligns the 4 workspace members 0.1.0 → 0.2.0 to match root/plugin.json (so coherence holds); uv.lock already had 0.2.0, so uv sync --locked passes.
• Install specs stay @main — they flip to @vX.Y.Z only when the release workflow runs (and the tag is created on merge).

Cutting 0.3.0 after this merges

Actions → release → enter 0.3.0 → review the auto-opened PR → merge. The reconsolidation feature (already on main) ships as v0.3.0. No version numbers hand-edited.

Verification

• All shell bash -n clean; all 3 workflows parse as YAML; set-version.sh round-trip + check-version-coherence.sh verified locally at both 0.2.0/@main and 0.3.0/@v0.3.0.
• uv sync --locked passes; daemon tests green after the bump.

🤖 Generated with Claude Code