One restart case I would add is the gap between saving NextIn and calling ApplicationMessage. In this sketch, a process exit after the counter is saved can leave the application without that fill, while its resend has a sequence number below NextIn and is ignored as a duplicate. I would test that exact stop point with an unapplied fill, restart from the saved counters, and assert that reconciliation restores it once. The sequence file and the application ledger need an explicit recovery boundary.