[AI] Use declared inputs for input-aware codegen on compiled systems

[SebastianM-C]

unbound_inputs classifies an input as bound if it appears in an equation together with variables from another namespace. That heuristic is only meaningful before flattening: after mtkcompile, connection/output equations are eliminated, so any effective input co-occurs with variables from other components — unbound_inputs is empty for every compiled hierarchical system.

Three codegen entry points still use it as their default input set and silently degrade on compiled hierarchical systems:

• generate_control_function warns "No unbound inputs were found in system." and generates dynamics with the controls bound at their operating-point values
• BVProblem computes n_controls = 0, mis-shaping f_prototype
• calculate_control_jacobian returns an empty jacobian

(We hit the first one through JuMPDynamicOptProblem on a hierarchical vehicle model: the NLP ended up with control-free dynamics and Ipopt "converged" in a handful of iterations to a pseudo-optimal constant-input trajectory.)

This PR adds default_codegen_inputs(sys) — inputs(sys) for scheduled systems, where the declared inputs are the contract mtkcompile was built around (stored in the inputs field), falling back to the unbound_inputs heuristic for unscheduled hierarchies — and uses it at those three sites. ODEInputFunction, already fixed to inputs(sys) in #4406, is switched to the same helper for consistency.

Includes a regression test with a minimal two-component system whose input is eliminated into a cross-namespace equation, covering the ODEInputFunction default and calculate_control_jacobian.

Also included: repairs to make the Optimization test group runnable again

The Optimization test group could not resolve or pass on current registry state, so two additional commits fix that (verified locally: the full dynamic_optimization.jl file passes, including the CasADi paths):

1. Migrate off DiffEqDevTools tableaus. DiffEqDevTools v3 removed the construct* tableau functions (moved to OrdinaryDiffEqExplicitTableaus / OrdinaryDiffEqImplicitTableaus), and v2's DiffEqBase cap conflicts with MTKBase's DiffEqBase ≥ 7.2 requirement, making the test env unresolvable either way.
2. Fix DynamicOptProblem reconstruction under remake/setproperties. The problem structs collected kwargs as positional varargs (storing a Tuple); current SciMLBase remake asserts values(prob.kwargs)::NamedTuple and reconstructs via keyword call, and ConstructionBase setproperties reconstructs with all six fields positionally. This broke solve → remake(prob, p = new_p) for problems with tunable parameters (the parameter estimation tests).

🤖 Generated with Claude Code