[M9] Add thin transport adapters for structured tool consumers

[Teakowa]

Parent: #10

Depends on: #57

Planning status: provisional until the M8 v1 gate is complete.

Goal

Expose Wright's owned structured tool API through practical transport adapters without making any transport the core architecture.

Scope

• Provide a stable local/stdio adapter for structured request/response workflows.
• Evaluate JSON-RPC where it materially simplifies multi-request/session consumers.
• Add an MCP adapter only if agent integration evidence justifies it, implemented as a thin mapping over Wright-owned operations.
• Preserve capability/version negotiation from the underlying tool API.
• Define cancellation/session/error mapping needed by selected transports.
• Keep transport crates/modules independently replaceable.

Non-goals

• Designing Wright core around MCP, JSON-RPC, or another protocol.
• Embedding prompts/model-provider logic.
• Duplicating semantic operations separately per transport.

Acceptance criteria

• Selected transport adapters expose the same semantic/tool operations and structured errors as the owned service.
• Tool/API behavior remains testable in-process without a transport.
• Adding/removing a transport does not change compiler/analyzer contracts.
• Any MCP support, if included, is demonstrably a thin adapter rather than the public semantic model.

[Teakowa]

Delivered in commit 03115d9 (wright-serve).

• stdio JSON-lines adapter and JSON-RPC 2.0 adapter expose the same ToolService operations and structured errors; equivalence with in-process consumers is tested (crates/wright-cli/tests/serve.rs: capabilities, rules, findings, costEstimate, workflows, malformed-request errors).
• Capability/version negotiation preserved across transports.
• MCP intentionally not implemented — no agent-integration evidence justified it in v1 (documented in docs/embedding.md). Transports are independently replaceable; compiler/analyzer contracts unchanged.