Define Agent Spec schema versioning and compatibility semantics

[schickling-assistant]

Problem

Agent Spec has no explicit schema version or defined compatibility policy. Additive fields can currently ship safely, but a future semantic or grammar change would leave authors and runners without a reliable way to distinguish supported declarations from silently misinterpreted ones.

This should be designed independently from the additive stable-identity/display-name split.

Design questions

• What identifies the schema and version across canonical KDL and the supported secondary formats?
• Which changes are additive, deprecated, or breaking?
• Must unsupported major versions fail closed during discovery and validation?
• How do renderers, st2, eval fixtures, and external readers advertise their supported range?
• What migration and rollback evidence is required before retiring a schema version?
• Should catalog-wide validation require one version, or permit explicitly supported mixtures?

Acceptance direction

• Version semantics are documented before the first version-gated change.
• Unsupported declarations fail with stable machine-readable diagnostics.
• Executable tests cover supported, unsupported, and mixed-version catalogs.
• The design does not introduce indefinite dual parsing or silent fallback behavior.