chore: merge v2/main for the v2.1.0 milestone release

[cliffhall]

Closes #1876

The first v2/main → main milestone merge. Brings the v2.1.0 payload — 14 commits — onto the release branch.

⚠️ This PR currently has 8 conflicts, and #1876's "expect ZERO conflicts" prediction is stale. Read the section below before merging; the resolution path matters, because the obvious one re-introduces the lineage problem #1868 was closed to avoid.

What's in it

Full grouped breakdown in #1876's milestone overview comment. In brief:

Group	PRs
Security & dependency hardening	#1899 (GHSA-p63j-vcc4-9vmv critical, @vitest/* → 4.1.10), #1900 (eslint 10, clears the brace-expansion DoS)
Tree-swap recovery	#1869 (Claude workflow + .mcp.json), #1871 (dependabot, .gitattributes, CoC), #1867 (SECURITY.md)
Contribution model & branch policy	#1866, #1879, #1884, #1894 (issue forms)
Board & triage process	#1892 (Incoming status, Priority field, triage rubric)
Protocol correctness	#1847 — the only runtime behavior change in the milestone
Merge convergence	#1880, #1881
Tooling reliability	#1895

User-visible surface is small: #1847 (tools/call now sends the SEP-2243 Mcp-Param-* headers, fixing rejection by strict modern servers), the Node engine floor moving >=22.7.5 → >=22.19.0, and the issues-only contribution model (#1894, #1884). Everything else is repo infrastructure a consumer never sees.

The conflicts, and why the prediction was stale

#1876 measured the conflict set when the only divergence was the README, and concluded #1880 would reduce it to zero. Since then main received 8 post-swap commits that v2/main never took — #1843 (SECURITY.md restored), #1842 (2.0.0), #1841 (vite 8.1.5), #1837 (dep sweep), #1836, #1835, #1834, #1832, #1831 — and on the other side #1899 and #1900 regenerated every lockfile. So:

File	Conflict	Cause
README.md	content	main's restructure vs. #1880's convergence
SECURITY.md	add/add	restored independently on both sides — #1843 on main, #1867 on v2/main
package-lock.json (root)	content	2.0.0 bump + dep sweep vs. eslint 10 regeneration
clients/{web,cli,tui,launcher}/package-lock.json	content	same, four times
clients/web/package.json	content	main's rc-series deps vs. #1899/#1900's resolved set

None is semantically hard — the lockfiles should be regenerated from a clean npm install, not hand-merged, and for SECURITY.md / README.md / clients/web/package.json the v2 side is authoritative (it is the newer content, and #1880/#1881 exist specifically to converge them).

⚠️ Do not resolve these with GitHub's web "Resolve conflicts" button

That editor commits the resolution to the head branch — i.e. it merges main into v2/main. That is precisely the back-merge that #1868 was closed to avoid, because it drags main's pre-swap v1 lineage into the develop branch's ancestry permanently.

The clean path, which keeps v2/main untouched:

git fetch origin
git checkout -b v2/chore/milestone-merge-v2.1.0 origin/main
git merge --no-ff origin/v2/main      # resolve here, on a throwaway branch
#   → lockfiles: take v2/main's, then regenerate with a root `npm install`
#   → SECURITY.md / README.md / clients/web/package.json: v2/main's side
npm install && npm run ci             # gate it before it becomes the release
git push origin v2/chore/milestone-merge-v2.1.0

…then retarget this PR (or open one from that branch) into main. main's ruleset requires a PR either way — see below.

Merge mechanics (main is ruleset-protected)

Classic branch protections are not configured, which is misleading: two active rulesets target ~DEFAULT_BRANCH, and one of them (2749948) grants bypass to nobody, repo admins included.

• A PR is mandatory — git push origin main will be rejected.
• 1 approving review required, from someone other than the author. A Copilot approval does not count.
• The build check must pass.
• allowed_merge_methods includes merge, so the intended --no-ff merge commit is permitted — merge via the button / gh pr merge --merge, not a local merge + push.
• npm version cannot be pushed to main either, for the same reason. Fold the version bump into the merge branch, or follow up with a second PR.
• Not blockers, verified: require_code_owner_review is inert (no CODEOWNERS anywhere), and the release tag is unrestricted (the only tag ruleset matches refs/tags/1.*).

Note on Closes #1876

main is the default branch, so that keyword will auto-close #1876 on merge. Its checklist still has post-merge items (cut the release, confirm @claude works again, confirm Dependabot targets v2/main, release notes) — reopen it after merging, or move those items out first.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU

[cliffhall]

Superseded by #1903.

This PR was v2/main → main directly, which came up CONFLICTING in 8 files. Resolving them here would have meant GitHub's web conflict editor, which commits to the head branch — merging main into v2/main, exactly the back-merge #1868 was closed to avoid.

#1903 instead merges v2/main into a branch cut from main (v2/chore/milestone-merge-v2.1.0), so v2/main's ancestry is untouched while the merge commit still carries its tip (834fd2d7) as the second parent. All eight conflicts resolved to v2/main's side, npm run ci green on the merged tree.