make pydantic model for op_system

[MacdonaldJoshuaCaleb]

Current parsing hot spots: the normalization pipeline in specs.py handles axes, kernels, operators, templated state/alias expansion, helper macros (sum_over, integrate_over), chain sugar, and kind routing (expr vs transitions). Safety/AST guards live in compile_rhs before execution.

Goal: replace the bespoke “validate dicts + raise ValueError” logic with Pydantic models that (a) preserve today’s normalization semantics, (b) keep the standardized error surface, and (c) support two modes: a strict/checked parse for user input and a fast/unchecked path when the engine already guarantees shape.

Proposed model sketch:

• Discriminated union on kind: ExprSpec and TransitionsSpec inheriting from a base RhsSpec.
  Shared fields: state, optional axes, aliases, kernels, operators, chain etc.
  Axes: CategoricalAxis (requires coords), ContinuousAxis (coords or domain+size, spacing, optional units).
  Expr-specific: equations mapping (templated keys allowed), optional state_axes.
  Transitions-specific: transitions list (templated from/to/rate/name), hazard semantics.
  Kernels/operators: typed submodels reflecting the checks in specs.py.
  Templates/macros: keep string-level helpers (_expand_state_templates, _expand_alias_templates, _expand_transition_templates, _expand_helpers in specs.py but feed them from validated model instances.

Checked vs unchecked mode:

Offer RhsSpec.model_validate(...) for user-facing strict parsing (mirrors current ValueError/TypeError surfaces).
Offer RhsSpec.model_construct(...) (or a thin wrapper) for engine-trusted specs to skip validation costs.
Keep downstream normalization (expansion + AST whitelist) the same so compile-time safety stays intact.

Addresses comments in #7