Trajectory reporter improvements

[PascalSalzbrenner]

Summary

In batch optimize runs, I found I was getting a large number of inconsistent trajectory warnings, alongside messages that arrays would be truncated. Digging into this surfaced a few behaviours which I think could act more consistently, alongside a bug. This PR addresses this:

1. inconsistent trajectory messages triggered when any property array did not end on the same step as the positions array. But this is frequently the case when state_frequency and prop_frequency differ, and should therefore arguably be a legitimate case. Resuming from the positions array prevented this if it trailed (consider positions written every 20 steps, and potential energy written every 10: a stop at step 110 would see positions at 100, and potential energy at 110). The change in the PR now resumes from the largest step across all arrays instead: writing strictly beyond it satisfies the per-array monotonicity that is the storage layer's only invariant, whatever cadence each array uses. The inconsistent last steps warning has been dropped from TorchSimTrajectory.__init__, because it has no true-positive case reachable through the runners now.
2. truncate_to_step in __init__ was a no-op because the only caller passed it self.last_step, so the if self.last_step == step: return always triggered. I repaired it so its early return tests every array rather than positions along. It is no longer called in __init__, but available & used as an explicit recovery tool for callers reconstructing state from a trajectory.
3. The final state was not generally recorded in the trajectory as it would only be recorded if it happened to end on a step divisible by the write cadences. I added force to TrajectoryReporter.report to bypass the frequency gates, skipping any array already at or beyond the step so a run ending on-grid is not double-written. optimize pops converged systems out of the batch mid-run and immediately repoints the reporter at the remainder, so each system's final frame is written at the moment it converges, through the handles still open for its batch. A single write before finish() would miss every system that converged earlier. Note that trajectories that previously ended off-grid gain one frame, so consumers inferring a time axis from frame order rather than the recorded steps will see a shorter final interval.

Checklist

Before a pull request can be merged, the following items must be checked:

• Doc strings have been added in the Google docstring format.
• Run ruff on your code.
• Tests have been added for any new functionality or bug fixes.

[janosh]

thanks a lot @PascalSalzbrenner! improvements to trajectory reporting are much needed and appreciated!