syscall deadlocks MPI Dynamic Process Management

GekkoFS's LD_PRELOAD interceptor deadlocks MPI dynamic process management. It hooks every syscall in every process, including PMIx's handshake, so a resize's never rendezvous. I worked around it with GekkoFS's FUSE client instead. Suggestion: can we make the interceptor tolerate MPI_Comm_spawn? Fixing this would let us drop FUSE entirely [jobs 44345211, 44353917]

Uncovered once Bug 7 stopped hiding it. dmr_check() is called at the end of every loop iteration including the last, so after the final timestep the benchmark checkpoints, resizes, and spawns an entire new generation whose only remaining job is to exit. Job 44345211 stalled there (RECONFIG#2, shrink 8 → 2 nodes):

448 old ranks (age ~1134 s) + 112 new ranks (age ~926 s) alive simultaneously,
every one parked in:
  MPI_File_open -> mca_common_ompio_file_open -> mca_common_ompio_set_view
                -> mca_coll_han_allreduce_intra -> ...bcast_intra_binomial
GekkoFS client logs: 0 bytes of growth over 45 s, newest write 20 min earlier

Zero GekkoFS traffic with everyone inside MPI_File_open means this one is genuinely stuck at the MPI level, not slow — the outgoing generation writing the checkpoint and the incoming one reading it, neither making progress. That is the distinction Bug 7 taught: sample twice, or measure an independent progress signal. The client-log byte count is the cheap one here.

The dmr_check() call is now guarded with if (current_iteration < TIMESTEPS), which is worth having regardless — resizing for zero remaining work is pure waste. But that only skipped the last iteration's resize, so at TIMESTEPS=10 the stall came straight back at the second resize (job 44353917, stuck at RECONFIG#2 with all 8 daemons healthy).