feat(mcp): expose blocks.delete/deleteRange via superdoc_edit

[jacobjove]

Summary

Wires the existing document-api blocks.delete / blocks.deleteRange ops into the MCP tool surface as two new superdoc_edit actions — delete_block and delete_block_range — so an MCP client can remove an entire block node, not just its text. Closes the gap where deleting a heading/paragraph's text leaves an empty container that still renders as block spacing.

Proposed in #3586 (surface options A/B/C discussed there). This PR implements option A.

What changed

• Contract (packages/document-api/src/contract/operation-definitions.ts): intentGroup:'edit' + intentAction:'delete_block' on blocks.delete; intentGroup:'edit' + intentAction:'delete_block_range' on blocks.deleteRange; one disambiguation sentence and one inputExample in INTENT_GROUP_META.edit.
• Regenerated via pnpm run generate:all: apps/mcp/src/generated/{catalog,intent-dispatch.generated}.ts, packages/sdk/langs/browser/src/intent-dispatch.ts, packages/sdk/tools/intent_dispatch_generated.py.
• Tests (apps/mcp/src/__tests__/protocol.test.ts): action-enum assertion plus three end-to-end cases asserting physical block removal (block-count decrement + nodeId absence) — one demonstrating the text-delete-leaves-empty-container bug vs delete_block removing it, and one asserting delete_block_range removes a contiguous top-level span (deletedCount + spanned nodeIds absent, with a neighbor outside the range surviving so the delete is proven bounded).

Addressing

delete (existing) takes a text ref; delete_block takes target:{kind:'block',nodeType,nodeId}; delete_block_range takes start/end (each a {kind:'block',nodeType,nodeId} top-level block, inclusive). The delete_block name is forced by the existing delete collision in the edit group.

Verification

apps/mcp 41 pass (4 new) · document-api 1480 pass (blocks + contract-parity) · conformance 1198 pass · codegen incl. cross-lang-parity (Node↔Python) 57 pass · typecheck 0 new errors vs baseline.

Limitations

• supportsTrackedMode: false, so block-node removal isn't recordable as a tracked change (cf. feat(track-changes): block-level structural tracked changes for tables #3343 for tables).
• Does not add a superdoc_mutations block.delete step (option C); a sound follow-up.
• blocks.delete overlaps tables.delete/lists.delete as the type-agnostic primitive; the type-specific tools remain.
• The delete_block_range contract entry carries the disambiguation sentence but not its own inputExample (the edit group example covers delete_block); deferred until the maintainer surface decision in MCP: expose block-node deletion (blocks.delete / blocks.deleteRange) via superdoc_edit #3586 (option A vs a dedicated superdoc_blocks tool vs a superdoc_mutations block.delete step) is settled, to avoid regenerating prose that a surface change would rewrite.