RestartFixture
What DurableStoreConformanceSuite.restart hands back: a store reopened onto the same medium, and what this backend claims about surviving a process exit.
Sealed rather than a store plus a boolean, so the two cannot drift apart: a subclass makes one decision, in one place, and the suite dispatches on it. Neither arm is an opt-out — see DurableStoreConformanceSuite.restart for why a nullable hook would have been, and what each arm can and cannot detect.
Top-level rather than nested so a fixture helper outside a suite subclass can build one.
Inheritors
Types
This backend commits to a medium that outlives the process, and store is a new handle onto the one the restarted store wrote to. Everything durably written before the restart must be readable through it, and everything deleted must still be gone.
This backend keeps nothing across a process exit, and store is the fresh, empty store a restarted process would get — InMemoryDurableStore, or any other backend whose own KDoc says it is not crash-safe.