Retry locating particles that start on a surface coincident with another

[GuySten]

Description

Particles split by weight windows at a surface crossing can be lost when another surface coincides with the crossed surface. This was reported in #4140, where 9 of 10 particles were lost ("Could not find the cell containing particle") and the leakage fraction was 0.1 instead of 1.0.

Cause. In the reproducer, the particle crosses x = 62125.05 (surface 3) inside a universe, and the surface weight window checkpoint splits it there. The secondaries are banked with surf_id = +3, so when they start, OpenMC knows only that they are on the positive side of surface 3. Surface 4 has exactly the same coefficients, and the root cell region is -1 | -2 | -3 | 4. After a track of about 1.5×10⁵ cm, roundoff places the banked position 2.9×10⁻¹¹ cm below the plane, more than FP_COINCIDENT (10⁻¹² cm), so 4 evaluates to false. Together with -3 being false from the surface flag, no root cell contains the particle and it is lost. The primary particle is not lost because it never re-searches the root level. Instead, the same inconsistency causes the zero-length "crossing surface 4" event visible in a trace.

Fix. When a particle that has a surface set cannot be located at the start of its history, it is now moved forward by TINY_BIT along its direction with the surface cleared, and the search is repeated. This is the same fallback Particle::cross_surface already uses when a particle cannot be located after crossing a surface. Particles without a surface set, such as source particles from point sources, are unaffected, so a genuinely undefined region is still reported as lost.

Test. test_split_on_coincident_surfaces in tests/unit_tests/test_lost_particles.py builds the model from #4140 with the Python API and checks that all of the weight leaks. It fails on develop (leakage 0.1) and passes with this change.

Note. This fixes the symptom at the point where particles are banked on a surface. The underlying issue is that the "on surface" flag covers only one surface while other coincident surfaces are evaluated from the position with an absolute tolerance, which becomes smaller than the floating-point resolution of coordinates beyond about 10⁴ cm. Treating geometrically identical surfaces as one when deciding which side a particle is on would also remove the spurious zero-length crossing. That could be a follow-up.

Fixes #4140

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)