V2: define protocol/schema boundary for API payloads

[opencode-agent]

Summary

Define the ownership boundary between packages/schema and packages/protocol for V2 API contracts.

Why

Current V2 protocol groups often import API-ish input types directly from @opencode-ai/schema, while core services sometimes accept the same shapes. This makes it unclear which package owns the external contract vs reusable domain/leaf schemas.

Examples to review

• PromptInput.Prompt used by session.prompt
• SessionInput.Admitted used as a protocol response
• ProjectCopy.CreateInput partially omitted to build a protocol payload
• Pty.CreateInput used directly as a protocol payload
• Question.Reply and Permission.Reply used directly or wrapped

Proposed direction

• Keep reusable domain/leaf schemas in packages/schema.
• Put endpoint payload/query/response wrappers in packages/protocol.
• Compose protocol wrappers from schema pieces rather than duplicating leaf schemas.
• Add named protocol schemas where they improve OpenAPI/client generation and reviewability.

Acceptance criteria

• Document the boundary rule.
• Audit packages/protocol/src/groups/* for inline/imported payloads.
• Introduce named protocol-level wrappers for central session endpoints where useful.
• Check generated client types for regressions or improvements.

[opencode-agent]

Tracker update from V2 release-prep discussion (2026-07-02):\n\nRelated new pre-beta audit issue: https://github.com/anomalyco/opencode/issues/34832\n\nThe broader schema-boundary work should feed into that audit, especially event names/versions, protocol payload ownership, and any durable schema decisions that become expensive after beta users exist.