Resolve #508

[slopqueue]

Resolve GitHub issue #508: Silent trajectory corruption under symplectic-recovery storms (timestep starvation)

Issue body:

Summary

When the fixed-step symplectic integrator is starved of timestep resolution in a chart whose coordinate surfaces are far from flux surfaces, the recovery path degrades trajectories silently: markers accumulate thousands of recovery events per marker and produce physically wrong (excess) losses, while almost no retry_exhausted events are reported and the run exits cleanly.

Observed case

• SIMPLE 69fe8c364d55452ee203bbf06836510caafa7540, libneo e2b281b1bc9f9f48f9526622445e0b2c0f8a4984.
• Proxima 5C (QI, 4 field periods) map2disc chartmap (non-flux-aligned harmonic-extension chart), 3.5 MeV alphas from s=0.2, 500 ms traces, implicit midpoint, npoiper2 = 256.
• Result: 740 of 8192 markers lost, versus 424–429 for three other charts of the same wall/ensemble (verified marker-matched: on identical markers the corrected run agrees with an independent loss-detection method to a median loss-time difference of 79 µs).
• Diagnostics on 33 inspected corrupted markers: all 33 showed corrupted trajectories with roughly 7600 symplectic recovery events per marker, but only 6 retry_exhausted events total were surfaced. No warning or error otherwise.
• With npoiper2 = 512 (only changed parameter) recoveries drop to about 28 per marker and the excess loss disappears (424/8192).

Problem

A recovery mechanism that fires thousands of times per marker is no longer recovering — it is integrating a different, wrong trajectory. The user gets no signal: exit codes, logs, and retry_exhausted counts all look nominal.

Suggested robustness improvements

1. Count recovery events per marker and flag markers whose count exceeds a threshold (e.g. mark them with a distinct exit code such as recovery_storm instead of a physical loss/confined status).
2. Emit a run-level warning when the ensemble-mean recovery rate per timestep exceeds a sane bound, suggesting a smaller timestep.
3. Consider making repeated recovery within a short window escalate to retry_exhausted rather than resetting the retry budget.

Full investigation record (private project, available on request): runs/simple-production/map2disc-leak-investigation.md in the JNME-D-26-00030 revision repository.

Summary: Recovery Storm Detection (Issue #508)

Closes #508

slopqueue-task: 019fb70f317f-7493b7b1

The automated test gate failed, so this PR is a draft:

$ pytest -q
sh: 1: pytest: not found

[exit] exit status 127