MCP tool schemas do not advertise --no-record for recordable commands #1310

Split out from the --no-record forwarding work (#1304 → #1305 → successor seam PR), as agreed: discoverability, not function.

What

Once forwarding moves to the shared seams (commonInputFromFlags + readCommonInput + commonToClientOptions), noRecord will work at runtime for every recordable command across CLI / Node client / MCP.

But readCommonInput is runtime-only: it is not part of a command's declared field metadata, and the MCP tool inputSchema is generated from that metadata. So MCP tool schemas will still advertise noRecord only for the commands that declare it as a field — open (management/app.ts:51), get/is/find (interaction/metadata.ts:179), snapshot (capture/snapshot.ts:34).

Net: an MCP client can pass noRecord to press and it will be honoured, but nothing in the advertised schema tells it that it may. For an agent-facing surface, an undiscoverable flag is close to a non-existent one — which is the same class of problem as the original silent drop, one layer up.

Why not bundled into the seam PR

Bundling schema-surface changes into a forwarding fix blurs both, and the schema change is a wider review surface (it touches every recordable command's advertised tool contract). The runtime fix is the urgent half.

Options

1. Declare a shared record-control field group on every recordable command's metadata — most explicit, but re-introduces per-command declarations, i.e. exactly the hand-listing the seam work is removing.
2. Teach schema generation to append the common runtime fields (noRecord) to recordable commands' inputSchema, driven by the same classification the completeness gate will introduce.

(2) composes with the planned recordsSessionAction descriptor classification + completeness gate and keeps one source of truth, so it is likely the right shape — the gate says which commands record, and the schema generator reads that rather than a second hand-list.

Context

• Original silent-drop bug: --no-record is silently dropped by the press/fill/click readers — the documented state-repair flow doesn't work via CLI #1304
• fix(cli): forward --no-record from every recordable command reader #1305: reader-layer fix; inert for most commands — see the correction comment on that PR for measured numbers (32+ surface, 5 working)
• fix(replay): default-exclude observation-only reads from repair heals, add --record opt-in (#1271 stage 2) #1303: added the metadata declarations that made get/is/find/snapshot work end-to-end
• --record is out of scope here: it is deliberately narrow (snapshot/get/is + dynamic find) and already declared where it applies