Fix issue #483

[lohedges]

This PR closes #483. Dynamics.run() stepped the integrator in fixed blocks of 50 steps, and after each block _exit_dynamics_block() calls getState(getEnergy=True), which is a full force evaluation and a GPU sync. The blocks only exist to update the progress bar; crash recovery is unaffected by them, since it restores the snapshot taken before run() was called. Each block now runs to the next frame or energy save, or the end of the run, and the 50 step cap is applied only when the progress bar is visible. ProgressBar gains an is_silent() query for this, tracked in the Python wrapper alongside set_silent(). Because a block can now be long, its length is fixed from both the next frame and the next energy save before either flag is set, so that one save shortening the block cannot move the other; a side effect is that saves now land on the requested step rather than at the end of a 50 step block. The existing dynamics tests cover the frame and energy scheduling and pass with the progress bar both shown and silenced.

On a 46646 atom protein-ligand system at 4 fs on an RTX 5070 Ti, with the progress bar silenced as somd2 does, Dynamics.run() with nothing saved went from 0.380 to 0.360 ms/step against 0.356 ms/step for the raw integrator, and with an 11 window energy scan every 2 ps from 0.381 to 0.367 ms/step.

• I confirm that I have merged the latest version of devel into this branch before issuing this pull request (e.g. by running git pull origin devel): [y]
• I confirm that I have added a changelog entry to the changelog (we will add a link to this PR as part of the review): [y]
• I confirm that I have permission to release this code under the GPL3 license: [y]

[chryswoods]

👍

[lohedges]

Failures are GitHub actions network issues causing IO errors.