Associate an alias with an already-observed nonpending execution.
Bind a prepared start; only exact lost-write readback can recover.
Claim only this observed modern-unbound reservation.
Read one reservation. A PURE read: no lazy DDL, no upsert, nothing that would make consulting a key mutate the database — which is what lets a read-only drain inventory and every replay path use it freely, and what keeps a read-only replica or a revoked-write incident a degrade rather than an outage.
An absent TABLE reads as an absent reservation, because on a deployment where no key has ever been used those are the same fact.
Release only the exact unbound claim, without readback recovery.
Every reservation naming one of these runs, for the purge and the inventory. Chunked by the caller; this method binds exactly what it is given, so a caller must respect D1's 100-parameter statement limit.
Decide which run this key means, creating the reservation if it is new.
INSERT OR IGNORE then READ BACK — the resource-ownership idiom, and the only shape that is correct without a transaction: the insert is the race, the read-back is the result, and every caller that lost the insert reads the winner's row rather than its own intention. Two callers can therefore never both believe they created the reservation, whatever order their statements interleave in, and neither needs to know it raced.
This is the ONE method that may create the table. A reservation is the
first write anything here makes, so the schema belongs on its path and
nowhere else — in particular not on read, where lazy DDL would turn the
deployment's read-only drain inventory into a write.
Settle every alias of this complete physical/logical execution.
The deployment's start reservations, over the SAME D1 database its snapshots, its resource owners, and its execution fence live in — so a reservation cannot be separated from the run it reserves by any binding mistake.