Whether the reserved run is executing RIGHT NOW — asked only when nothing is persisted, and only to separate "still working" from "died holding the claim". Never a timer (see the module header).
KNOWN WINDOW — the claim-to-dispatch gap. The winning CAS lands on the Worker, and the object that would report the run live only learns about it one dispatch later. A concurrent retry probing inside that gap is told UNRESOLVABLE for a run that is about to execute perfectly well.
That is a FALSE ALARM, never a lost or duplicated run: the claim still
stands, the winner still executes, and the caller's next retry replays the
persisted summary. Closing it would take moving the claim into the target
object itself, so that started becomes observable only from inside the
body that is already executing. It is deliberately NOT closed with a grace
period: a bound short enough to cover a dispatch is indistinguishable from
the timer this design rejected, and once a timer exists somebody will grow
it to cover a slow run and re-open the double-charge it was rejected for.
The reserved run's persisted state, or undefined when nothing has been persisted yet. This is the FIRST question asked on every replay, because a persisted run makes every other branch moot: the work happened, its outcome is readable, and the honest answer to the retry is that outcome.
The two surface-specific reads the replay decision needs.