The row was read: serverFeature and serverVersion carry what was crushed.
The server answered in representation and holds NO such row — nothing was crushed.
The re-read could not conclude — mute network, refusal, unreadable body.
⚠️ The overwrite happens ANYWAY, and that is a decision (17/09/2026), not an
oversight. Making the write depend on a read the server may not grant — UPDATE
without SELECT is an ordinary permission split — would turn every conflict into a
quarantine, i.e. silently repeal the lastWriteWins policy. The record is written
with this outcome so the gap is visible rather than invented.
What the drain could learn of the server's row before crushing it.
🛑 THE ABSENCE IS ITSELF AN OBSERVATION, which is why this is three values and not a nullable feature. A conflict whose re-read failed and a conflict on a row the server no longer holds are different facts, and reading both as "no server version" would make the store say something false about the second. Same arbitration as
OutboxEntry.quarantineStatus, whose ABSENCE carries "the server never answered".