types-epic E batch 5: Zod MCP schemas for account core (15 tools)

[JSONbored]

Part of #7863 (types-epic E). One of 12 remaining tool batches — see #7863 for batch 1 (the pilot conversion: search_subnets, list_subnets, get_subnet, get_network_health, get_subnet_stake_quote, get_economics) and the wire-compatibility constraint this batch must preserve.

Scope

Convert these 15 MCP tools' inputSchema/outputSchema hand-written JSON Schema 2020-12 literals in src/mcp-server.ts's MCP_TOOLS registry to Zod-defined schemas, following the exact process #7863 established for batch 1:

1. For each tool below, define its input/output shape as a Zod schema. Where a tool mirrors a REST route already covered by schemas-src/routes/ (from types-epic B: generate OpenAPI 3.1 from the Zod layer; invert the schemas/ flow for covered routes #7860 and its batches), reuse that module's schema — share, never redeclare.
2. Replace inputSchema: {…literal…} with inputSchema: z.toJSONSchema(<tool>Input, { target: "draft-2020-12" }), computed once at module load. Same for TOOL_OUTPUT_SCHEMAS.
3. Handler signatures become async handler(args: z.infer<typeof <tool>Input>, ctx: McpCtx). This does not change WHERE validation happens (SEP-1303 tool-error semantics unchanged), only where schemas are DEFINED. If a converted schema surfaces that the current runtime accepts something the declared schema forbade (or vice-versa), that's a finding: align them per the tool's documented contract and record it in the PR body.
4. Hard wire-compatibility constraint: the emitted JSON Schema after conversion must be SEMANTICALLY equivalent per tool — same required sets, same types, same enum values, same additionalProperties posture. Cosmetic differences (key order, $schema presence, description strings) are acceptable; anything that changes what a client-side validator accepts is a regression. Run the equivalence-diff script from types-epic E: MCP tool input/output schemas via Zod — delete the hand-written JSON Schema literals #7863's batch 1 against every tool in this batch; every DIFF must get a bucket-(a/b/c) resolution, included in the PR body.
5. Zero JSON Schema object literals remain for these tools (grep-verified in review).
6. Do NOT hand-bump MCP_SERVER_VERSION or server.json's version — sync-mcp-version handles that post-merge. This adds no new tools, so no server-card regen is needed.

Tools in this batch (15)

• get_account
• get_account_entities
• get_account_balance
• get_account_root_claim
• get_account_children
• get_account_parents
• get_account_events
• get_account_subnets
• get_account_portfolio
• get_account_positions
• get_account_snapshot
• get_account_identity
• get_account_identity_history
• get_account_position_history
• get_account_stake_flow

Acceptance criteria

1. tests/mcp-server.test.ts passes UNCHANGED (its Ajv validation of outputSchemas is the independent referee — do not edit its assertions to make the PR pass; if an assertion fails, the schema conversion is wrong).
2. Full CI green; the equivalence-diff script reports PASS or resolved-DIFF for every tool in this batch, output included in the PR body.
3. Zero JSON Schema object literals remain for these tools (grep-verified in review).

Non-goals

• No dispatch/validation-flow changes, no new tools, no output-shape changes.
• No coverage beyond the tools listed above (further batches are separate sub-issues of types-epic E: MCP tool input/output schemas via Zod — delete the hand-written JSON Schema literals #7863).

[linear-code]

JSO-5931