API versioning

These can appear at any time and are not breaking. Write clients that tolerate them:

• New endpoints and new optional request parameters.
• New fields in response bodies (parse what you know, ignore the rest).
• New enum values in fields documented as open (e.g. new modes, new artifact shapes).
• New webhook event types — subscriptions only receive events they opted into.
• New error codes (handle unknown codes generically via the HTTP status).

Removing or renaming a field, changing a field's type or meaning, removing an endpoint, tightening validation on existing input, or changing auth semantics — none of that happens inside v1. A breaking change ships as a new versioned path.

• 90-day notice before any endpoint or version is retired, announced in the changelog and by email to affected API key owners.
• Sunset header — when the first deprecation ships, deprecated endpoints will carry an RFC 8594 Sunset header with the retirement date. This is a forward commitment: no endpoint has been deprecated to date, so you will not see this header today.
• Legacy surfaces stay up during their window — the per-key webhook mechanism (X-Mcp-Signature) is already documented as legacy; existing configurations keep working while subscriptions are the recommended path.

The MCP server follows the same philosophy: tool names and argument schemas are contracts. New tools, resources, and prompts are additive; argument-schema changes are deliberate, snapshot-tested events. Clients should list tools at connect time rather than hardcoding the inventory.