Roadmap: python-control integration (Phase 1 — state-space bridge, Phase 2 — NonlinearIOSystem wrapper)

Context

Following up on https://github.com/orgs/pathsim/discussions/195, this is
where the python-control integration for pathsim lives, split into two
phases.

Phase 1 — linear bridge (in progress)

The linearization design landed differently than originally scoped here.
pathsim/pathsim#237 (trim() + linearize_system()) was closed without
merging; the maintainer implemented linearization as a pure query instead
in pathsim/pathsim#239 — see
https://github.com/orgs/pathsim/discussions/195#discussioncomment-17779351
for the design rationale.

Simulation.to_statespace(inputs, outputs, t=None) (merged into
pathsim master, not yet in a PyPI release) returns a StateSpace
block whose A/B/C/D and state_labels/input_labels/output_labels
already match control.StateSpace's states=/inputs=/outputs=
kwargs. to_control_statespace(sim, inputs, outputs, t=None) here is a
thin wrapper around it, no adapter code needed. Unlocks control.margin,
control.root_locus, control.bode_plot, etc. on any pathsim
Simulation immediately.

trim() wasn't part of that merge and doesn't exist yet — planned as an
extension of Simulation.steadystate().

Phase 2 — nonlinear bridge (later)

Wrap an entire pathsim Simulation as a control.NonlinearIOSystem
(updfcn/outfcn), enabling full nonlinear simulation/operating-point
analysis through python-control's own tooling. Harder: needs adapting the
DAG-order algebraic-loop-resolution logic in pathsim core's
utils/linearization.py (assemble_linear_system) to work with nonlinear
per-block functions instead of Jacobians.

Start by reading Simulation.to_statespace and the to_control_statespace entry point, then compare their labels and A/B/C/D behavior with control.StateSpace. Phase 1 is done when the thin linear bridge exposes the documented python-control tooling; Phase 2 requires studying pathsim core's utils/linearization.py and assemble_linear_system before wrapping a Simulation as NonlinearIOSystem.