Release 2.4.0 step 1: bump version to 2.4.0 on v2/main #2141

Summary

Bump the root package.json version 2.3.0 → 2.4.0 on v2/main, as the first step of the v2.4.0 release.

Both branches currently read 2.3.0, and the v2.4.0 milestone is due 2026-08-26 with 0 issues still open — so the payload is ready to ship. Per the procedure established in #2010 / #2011 and first exercised for 2.3.0 (#2013 / #2052), the bump lands on v2/main before the milestone merge rather than on the milestone-merge branch afterwards. Doing it in the wrong order is what left v2/main stranded at 2.0.0 through two releases, so this issue exists to make step 1 explicit and hard to skip.

Minor, not patch: the payload carries new user-facing capability — the dedicated MCP App origin for _meta.ui.domain (#2056), app-rendered form elicitations (#1854), the file-backed secret store (#1950), tool-schema portability lint across all three clients (#1005), and the OAuth refresh-token toggle (#2068), among others.

Step 1 — the bump (this issue)

git checkout -b v2/chore/<this-issue>-bump-2-4-0 v2/main
npm version minor --no-git-tag-version
# PR → v2/main

⚠️ --no-git-tag-version is required. A bare npm version also creates a tag, and it would land on a v2/main commit — but the release is cut from main, so the tag belongs on the merge commit there (step 3). Tagging here produces a tag on a commit that is never released. It would also be v-prefixed, which does not match this repo's bare x.y.z tags.

Expected diff — two files, three lines:

package.json      | 2 +-      "version": "2.3.0" → "2.4.0"
package-lock.json | 4 ++--     top-level `version` AND packages[""].version

Then (not this issue)

2. Merge v2/main → main through the usual milestone-merge branch. It now carries the bump.

3. Tag origin/main and draft the Release:

   git fetch origin main
   git tag 2.4.0 origin/main && git push origin 2.4.0

   ⚠️ Tag origin/main, not a local HEAD after git checkout main && git pull — pull follows your configured merge/rebase strategy, so a divergent local main can produce a local commit, and git push origin <tag> pushes only the tag. That yields a release pointing at a commit nobody else has, and the publish job would not catch it (its tag-vs-package.json assertion still passes on a locally-merged commit).

Full procedure: Cutting a release.

Sanity checks

• Between step 1 and step 2, v2/main and main legitimately differ — v2/main on the version being built, main on the released one. Ahead is expected; behind means something went wrong.
• After the release, confirm they agree: git show origin/v2/main:package.json | grep version and the same for origin/main.
• Nothing in the repo asserts a specific version value, so the bump is a safe two-file change with no test impact.