Resolution (design, reasoning only; no executed tests): Drop last-write-wins. Settle the shared operation record with a monotonic lattice and conditional writes. Precedence: terminal completed/failed outrank unknown, timeout, and in-progress. A writer must not regress a higher-ranked outcome. Order A — success then timeout: the timeout path may set unknown only if the current status is still non-terminal (CAS or allowed-transition predicate). If the record is already completed with a result, the timeout write no-ops; the stored success stands. Order B — timeout then success: unknown may land first. A later verified commit upgrades unknown to completed and stores the result. Upgrade is allowed because completed ranks above unknown. Caller rule after local timeout: re-read the durable record (or on the next retry) and adopt any terminal outcome already present instead of blindly writing unknown over it. Optional strengthening when request identity matters: bind settlement to the reserved request fingerprint (and auth binding generation if used) so only a matching success may upgrade that reservation; mismatched outcomes are conflicts, not blind prefer-success-by-operation-id. Equal-rank terminals (distinct completed vs failed, or two completed payloads) need an explicit conflict rule beyond status monotonicity alone.

Updated finding (design, reasoning only; no executed tests): Status monotonicity alone (completed greater than unknown) is insufficient when a late success shares the operation identifier but not the reserved request fingerprint or authorization binding generation. Strengthened locked settlement: at reserve time, lock the triple (operation_id, request_fingerprint, binding_generation). A success may upgrade a non-terminal state to completed only if fingerprint and binding generation match that lock exactly via compare-and-swap or equivalent predicate on all three. A mismatched success is a settlement conflict: reject it; do not apply it; do not prefer it over unknown for that reservation. Why blindly preferring every successful response is unsafe: operation_id alone does not identify the intended request or the still-valid auth epoch. Accepting any committed success can (1) attach another request’s outcome to this reservation, (2) honor a response authorized under a superseded or revoked binding generation, (3) let a colliding or mutated retry complete the wrong work while the client believes its original request succeeded. Success is monotonic only for the exact reserved request under the exact binding. Timeout and other non-terminals still cannot demote a correctly locked terminal. Matching success may still upgrade unknown to completed under both completion orders.

Independent subagent review of the corrected locked settlement design (reasoning only; no repo or runtime tests). Verdict: ERRORS FOUND — lattice plus exact-reservation CAS blocks timeout regress and wrong-outcome attachment for matching success, but settlement remains incomplete. Critical gaps: (1) timeout/unknown writers are not bound to the reservation lock, so a stale timeout after rebind can overwrite a new attempt’s in-progress; (2) no rule between distinct terminals completed vs failed for the same reservation; (3) CAS gates status upgrade, not result identity when two matching successes disagree on payload; (4) rejected mismatched success leaves durable unknown with no defined recovery. High: equal-rank non-terminals underspecified; reserve/rebind concurrency and generation CAS underspecified; failed settlement must use the same lock match as success. What still holds: timeout cannot demote correctly locked terminals; timeout-then-matching-success can upgrade; success-then-timeout no-ops; blind prefer-by-operation-id alone correctly rejected; the triple lock is the right strengthening if every settlement writer is gated on it and terminal/payload conflicts plus post-reject recovery are defined.