Resolution (design): Replace last-write-wins with a monotonic settlement lattice on the shared operation record. State precedence: terminal success/failure outrank unknown/timeout/in-progress. Never allow a write to regress a higher-ranked outcome. Order A — success then timeout: timeout settlement is conditional (CAS/predicate): apply unknown only if current state is still non-terminal. If already completed with a result, no-op and return the stored success. Order B — timeout then success: unknown may be recorded first; a later committed success upgrades unknown → completed and stores the result. Upgrade is allowed because completed > unknown. Implementation sketch: single durable row keyed by operation id; updates use compare-and-swap on (status, version) or an explicit allowed-transition table. Callers that observe timeout still read the record afterward (or on retry) so they adopt the preserved success rather than inventing a new unknown write that overwrites it. Evidence: reasoning only; no executed tests against a live system.

Updated finding: plain status monotonicity (completed > unknown) is insufficient when a late success shares the operation id but not the reserved request fingerprint or authorization binding generation. Strengthened settlement: at reserve time, lock the triple (operation_id, request_fingerprint, binding_generation). A success may upgrade unknown→completed only if fingerprint and binding generation match the lock exactly (CAS/predicate on all three). Mismatched success is rejected as a settlement conflict—not applied, not preferred over unknown for that reservation. Why blind preference of every success 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/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. Evidence: reasoning only; no executed tests.

Independent subagent review of the corrected settlement design (reasoning only; no repo or runtime tests). Verdict: ERRORS FOUND — lattice + exact-reservation CAS blocks timeout regress and wrong-outcome attachment, but settlement is incomplete at equal rank and around reserve rebinding. Critical gaps: (1) no rule between distinct terminals completed vs failed for the same reservation—split-brain possible; (2) CAS gates status upgrade, not result identity—two matching successes with different payloads unspecified. Moderate: equal-rank non-terminals (unknown vs in_progress) underspecified; reserve/rebind with new fingerprint or binding generation undefined; mismatched success leaving durable unknown with no recovery/escalation path. Minor: upgrade should cover any non-terminal→completed/failed, not only unknown→completed. What still holds: timeout cannot demote terminals; timeout-then-matching-success can upgrade; success-then-timeout no-ops; blind prefer-by-operation-id alone correctly rejected.