test(operations): route read_notes through the registration gate

[AlexMost]

What

Routes read_notes's tests through the registration gate every MCP client crosses, and deletes the post-gate validation that gate makes unreachable. First of four PRs for #112.

registerTool wraps each tool's schema with coercion and z.object(...).strict(), then safeParses before the handler runs. The operations suite never crossed that seam — 100 handler-direct call sites, zero through a registration — so five tests documented behaviour production does not have:

Test's old pin	What the gate actually returns
paths: '' → INVALID_ARGUMENT	INVALID_PARAMS — paths: Too small: expected string to have >=1 characters
paths: [] → INVALID_ARGUMENT	INVALID_PARAMS — paths: Too small: expected array to have >=1 items
51 paths → INVALID_ARGUMENT	INVALID_PARAMS — paths: Too big: expected array to have <=50 items
content: 'none' → INVALID_ARGUMENT	INVALID_PARAMS — content: Invalid option
legacy fields key silently stripped	INVALID_PARAMS — Unrecognized key: "fields"

Three of validateReadNotesInput's four branches were therefore unreachable in production and green only because the tests entered past the gate; the fourth duplicated a zod type check. All four are deleted — only the string → string[] widening survives, inlined into its one caller. No client-observable behaviour changes: production already returned INVALID_PARAMS for every case above.

New helpers (test/_gate.ts), adopted by the next three PRs across ~220 call sites:

• callTool<T>(reg, args) — calls through reg.handler, unwraps structuredContent, and re-throws errors so existing rejects.toMatchObject({ code }) assertions keep working. Falls back to the text channel for the two tools that resolve with arrays (find_duplicates, get_similar_notes), which never populate structuredContent.
• expectToolError(reg, args) — for tests whose subject is the CallToolResult envelope itself.

New coverage read_notes never had: a stringified paths array coercing to two paths, and a vault argument rejected as an unrecognized key in single-vault mode (vaultParamShape contributes no vault param when one vault is registered).

Review found and fixed one real hazard before it multiplied: callTool initially minted an UNKNOWN_ERROR code for the code-less error envelope — a string production never emits. A future author reading it off a failure diff would have pinned it, re-seeding the exact bug this PR deletes. It now re-throws a plain Error when the envelope carries no code.

No test broke during the migration — every existing fixture already returned one reader item per requested path, and no input carried an undeclared key.

Tracking

Refs #112

OpenSpec change slug: operations-tests-through-gate

Spec deltas ride along in the change directory and sync on archive in PR 4: read-notes-content-modes (the invalid-content scenario said INVALID_ARGUMENT; the legacy-fields scenario said the key "is ignored" — the latter also contradicted tolerant-arguments §"Unknown keys remain rejected") and tolerant-arguments (the strict/coercing boundary applies uniformly; vault is an unknown key in single-vault mode).

Checks

• npm test — 1302 passed (105 files)
• npm run lint — eslint . clean
• npm run typecheck — tsc --noEmit clean
• openspec validate --all — 19/19

🤖 Generated with Claude Code