[M9] Validate external consumer integrations and API versioning

[Teakowa]

Parent: #10

Depends on: #56, #57, #58, #59, #60

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

Goal

Prove Wright's embedding/tool contracts from outside the core crates and define compatibility expectations for real consumers.

Scope

• Add external-consumer fixtures/examples that depend only on public APIs.
• Exercise compile/check/analyze/query workflows from representative automation/agent-style clients.
• Verify capability/version negotiation and backward-compatible evolution rules.
• Validate structured error behavior, session lifecycle, source identity, and concurrency/cancellation semantics where exposed.
• Test transport adapters against the same consumer-level scenarios without transport-specific semantic forks.
• Document which contracts are stable, experimental, or internal.

Non-goals

• Maintaining integration code for every agent product.
• Treating examples that import internal crates/types as valid public-API evidence.

Acceptance criteria

• At least one realistic external consumer uses Wright without internal IR imports or CLI scraping.
• API/version changes are covered by compatibility tests/policy.
• Transport and in-process consumers observe equivalent core semantics.
• Public/experimental/internal boundaries are explicit.

[Teakowa]

Delivered in commits 03115d9/58a9dde (crates/wright-consumer).

• A committed external consumer depends only on wright-driver (no internal IR imports, no CLI subprocess, no text scraping) and runs compile/check/analyze, all tool queries, and a validated rename over the corpus and Workshop inputs (tests/consumer.rs).
• API/versioning policy recorded in docs/embedding.md (stable/experimental/internal boundaries, additive v1 evolution); transport and in-process consumers observe equivalent semantics (tested).
• Examples that import internal crates are explicitly excluded as valid public-API evidence.