Add top-level `SystemSpec` discriminated union model

[jc-macdonald]

Summary

Add a top-level SystemSpec Pydantic model as a discriminated union of ExprSpec and TransitionsSpec, giving users a fully typed entry point to compile_spec().

Problem

After #20–28 create Pydantic models for every sub-structure (Axis, Transition, Mixing, etc.), nothing composes them into a top-level schema. compile_spec() still accepts dict[str, object] — users get no IDE autocompletion, no schema-level validation, and no clear documentation of the full spec shape.

Scope

• Define ExprSpec model: state, equations, axes, aliases, kernels, operators, constraints, state_axes, meta
• Define TransitionsSpec model: state, transitions, axes, aliases, kernels, operators, constraints, state_axes, meta
• Define SystemSpec = ExprSpec | TransitionsSpec as discriminated union on presence of equations vs transitions
• Update compile_spec() to accept SystemSpec | dict[str, object] (backward-compatible)
• Spec kind field becomes optional — discrimination handles it

Notes

This naturally subsumes #41 (infer spec kind from contents): a discriminated union on equations vs transitions keys eliminates the need for an explicit kind field.

Dependencies

Should land after sub-model issues are resolved:

• Add ExpressionString type #22 (ExpressionString)
• Add Axis pydantic model #23 (Axis)
• Add Transition Pydantic model #21 (Transition)
• Add Mixing pydantic model #24 (Mixing)
• Add Chain Pydantic model #26 (Chain)
• Add StateAxes Pydantic model #27 (StateAxes)
• Add Operator Pydantic model #28 (Operator)
• Add Constraint Pydantic model #58 (Constraint)
• NormalizedRhs model that is discriminated union of ExprRhs and TransitionsRhs #20 (NormalizedRhs discriminated union)

Related

• Infer specification "kind" from contents #41 (infer kind — subsumed by this)
• Revisit NormalizedRHS structure and naming. #5 (NormalizedRhs naming)