Currently, I think there's a scenario where the fuzzing engine finds a value that causes a crash but can't reconstruct or record it.

1. Worker finds a random mutation that expands coverage.
2. Worker sends that entry back to the coordinator.
3. Coordinator confirms entry expands coverage and sends it back to a worker for minimization.
4. During minimization, worker terminates unexpectedly.

During normal fuzzing, if a worker terminates unexpectedly, the coordinator can reconstruct the entry that caused the crash using the initial entry and the execution count and PRNG state in shared memory. That process is deterministic.

That won't work during minimization since the worker makes many small decisions along the way. For example, after removing a byte from a string, the worker might proceed with the shorter string or revert the change depending on whether the shorter string triggered the same coverage.

One possible solution is to log these minimization decisions in shared memory so the coordinator can reconstruct the minimized input after a crash.