Add a checked stepped_over to RotorLag

[naseem173]

Fixes #298.

Adds RotorLag::try_stepped_over, a checked variant of stepped_over for a variable-rate loop where the tick length was not already validated by RotorLag::new (for example, one computed from a pair of timestamps that can come out the wrong way round). A negative tick composes into runaway growth rather than a small backward step, since (-timestep / time_constant).exp() then exceeds one, so this is worth rejecting explicitly rather than leaving it to the caller.

What changed

• try_stepped_over validates only timestep (finite and strictly positive), matching stepped/stepped_over's existing "checking the command is the caller's job" behavior — the command vector is not checked here either.
• Reuses the existing PlantError::NonFinite / PlantError::NonPositiveTimestep variants; no new error variants needed.
• On rejection, self is left unchanged (covered by a dedicated test).
• Follows the codebase's existing try_ naming convention for a fallible variant living alongside an infallible sibling (e.g. try_with_connection_radius, try_normalized), rather than checked_, which this codebase reserves for arithmetic.

Testing

• cargo test -p multicalc rotor_lag (targeted) and cargo test -p multicalc (full suite incl. doctests)
• cargo test -p multicalc --features alloc
• cargo fmt --all --check
• cargo clippy -p multicalc --all-targets --features alloc -- -D warnings
• cargo doc -p multicalc --no-deps --all-features

Added 4 new tests: the checked step matching the fixed-rate model at the total elapsed time, rejecting a non-positive timestep, rejecting a non-finite timestep, and leaving the rotors untouched on rejection.