ci: upgrade to Changesets v3 and changesets/action v2

[kraenhansen]

Fixes #397.

What moved

Both packages were blocked on prereleases when #397 was filed; both have since shipped stable, so this does the coordinated bump it called for:

• @changesets/cli → ^3.0.0 (root devDependencies)
• changesets/action@v1 → v2 in .github/workflows/release.yml
• Renamed the step's inputs to v2's kebab-case scheme: publish: → publish-script:. Dropped the GITHUB_TOKEN env var — v2 reads it through a github-token: input that already defaults to ${{ github.token }}, same value.
• .changeset/config.json: bumped the $schema pin to @changesets/config@4.0.0 (what @changesets/cli@3.0.0 depends on). None of v4's breaking changes touch our config — no prettier key, baseBranch is already "main", no experimental snapshot option in use, and changeset tag (renamed to changeset git-tag) isn't used anywhere in our scripts.

Both had to move together, as #397 flagged: v3 dropped the New tag: <pkg>@<version> stdout line changesets/action@v1 parses to detect what published; the action's v2 line instead reads NDJSON git-tag events the CLI writes to $CHANGESETS_OUTPUT. CLI v3 with action v1 would publish but report published: false and push no tags/releases — a silent regression.

Correcting an assumption in #397

The issue expected this upgrade to let npm_config_force: true (added in #396) be removed, reasoning that v3's publish pipeline is pnpm-aware and would never invoke npm. That's true for pnpm pack/pnpm publish — verified here with strace, neither execs npm. But pnpm info (what changeset publish/publish-plan use to check what's already on the registry) is itself a passthrough to the real npm CLI: strace shows pnpm info <pkg> directly execves npm info <pkg>. That still trips npm ≥ 11's devEngines validation of this repo's own root package.json (devEngines.packageManager: pnpm, but the process running is npm), the exact failure #396 worked around.

So npm_config_force: true stays — there's no changesets- or pnpm-version bump that removes the need for it. I updated the workflow comment to reflect this instead of leaving it as a removal condition that isn't actually reachable. I also updated #397 itself so it reflects this rather than the original "prereleases are the only blocker" framing.

Verification

On Node 24 / pnpm 10.33 (this repo's pinned versions):

• pnpm exec changeset status and pnpm exec changeset publish-plan — the latter reproduces EBADDEVENGINES without npm_config_force, and completes cleanly with it (same shape as the pre-upgrade behavior), confirming the escape hatch is still both necessary and sufficient.
• pnpm run build, pnpm run prettier:check — pass.
• pnpm run lint — pre-existing, unrelated failures in apps/test-app/App.tsx (confirmed present on main without this change).
• pnpm test — pre-existing, unrelated failures in packages/host's permission-based path-utils tests (they assume file permissions restrict access, which doesn't hold running as root in this container; confirmed present on main without this change).

Not verified: the actual GitHub Actions publish path. The input/output renames and github-token default only get exercised once a "Version Packages" PR merges and the Release job runs the publish step for real, so this needs a live run to confirm end-to-end.

---

Generated by Claude Code

[kraenhansen]

@kraenhansen for review — couldn't request you formally since the PR is authored as you.

One thing worth double-checking on your side: I couldn't exercise the actual publish step through changesets/action itself (only the underlying changeset publish-plan/CLI calls locally), so the github-token default and the publish-script rename are unverified against a real Action run until the next "Version Packages" PR merges.

---

Generated by Claude Code