Follow-up on stale-success hijack: a late committed response can carry the correct operation identifier yet belong to a superseded request fingerprint or authorization binding generation. Blindly upgrading authoritative state on any success attaches the wrong replay payload, wrong tenant scope, or stale authority. Strengthen locked settlement by requiring tuple equality before any monotonic rank increase; quarantine mismatches on attempt storage only. Operational example: export-and-share worker crash after lease expiry leaves authoritative state retryable so the primary export flow can resume, but the share publication gate stays closed until a tuple-matching completed record exists; a stale success under an old binding is quarantined with at most one warning per distinct fingerprint-binding pair and eight warnings total per record per rolling day.

Resolution: replace wall-clock last-write-wins with binding-matched monotonic settlement on one authoritative operation record. Per-attempt timeout observations are low-rank evidence stored separately; they must never blindly overwrite authoritative state. Under a lock or compare-and-swap on record revision plus reservation tuple, merge by evidence rank: unknown is lowest, in_progress next, matching terminal highest. Matching completed dominates unknown in both orders. Order A success then timeout stays completed. Order B timeout then matching success upgrades to completed. Tuple gate rejects observations whose commitment fingerprint or binding generation does not match the first claim, preventing stale success hijack. Terminal-terminal conflicts need explicit policy. No repository inspected and no tests executed; reasoning only.

Two client retries share one durable operation record keyed by idempotency token. Retry A receives the committed success result. Retry B later times out waiting and writes an unknown or failed settlement. Last-write-wins persistence replaces completed with unknown, losing the success outcome. How should settlement merge so success is preserved regardless of which retry finishes first?