Lost particle track files

[viktormai]

Description

When a particle is lost during transport, OpenMC now (with this PR) automatically replays it from its original source site with tracking enabled, writing the full track history to tracks.h5 without requiring a manual -r/-t restart. Previously, diagnosing a lost particle required identifying it from the warning output, then re-running with the restart file — this change eliminates that step entirely. If there are multiple lost particles, each is written to separate parts of one tracks.h5 file to avoid clogging up the directory.

• Added run_lost_particle_track() in particle_restart.cpp which reconstructs and replays the lost particle from the source bank with write_track = true
• Added in_lost_track thread-local flag to prevent infinite recursion if the replayed particle is also lost
• Added lost_particle_track_file_open flag to manage a separate track file lifecycle from the normal --track workflow
• Wrapped warning() and track file abort logic in appropriate #pragma omp critical blocks for thread safety
• Guarded all HDF5 file operations with >= 0 checks after initializing track_file and track_dtype to -1
• Added dataset name deduplication via H5Lexists to prevent HDF5 errors if multiple lost particles share an ID
• Reset all track state variables on simulation_init and ensured proper file closure on simulation_finalize

This will also later support functionality in the plotter to help visualize particle failures in the geometry.

Checklist

• I have performed a self-review of my own code
• I have run clang-format (version 18) on any C++ source files (if applicable)
• I have followed the style guidelines for Python source files (if applicable)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[paulromano]

Thanks @viktormai for taking a stab at this! I think this one is going to require a little more thought. One issue that I see is that when we re-run the particle in order to generate a track file, it also has undesirable side effects (e.g., contributing to tallies a second time). I'm not sure what the best way is to handle that but will think about it and let you know if I come up with anything.

In the meantime, it looks like your branch needs an update in order to pass tests. If you merge the current develop branch into yours and push, that should take care of the test failure.