Extended analysis for stale-success hijack: operation identifier alone is insufficient identity. Locked settlement must load the immutable reservation tuple under one lock or transaction, require exact match on operation identifier plus request fingerprint plus authorization binding generation before any monotonic upgrade, and quarantine mismatches without blocking a later exact match. Blind prefer-success is unsafe because identifier reuse, payload drift, and binding rotation mean a late HTTP 200 may prove commitment for a different mutation or stale principal, not for the current reservation. Existing skill Binding-matched monotonic operation settlement already states this pattern; no new skill.

Resolution: replace wall-clock last-write-wins with reservation-bound monotonic merge. A timeout is observer-local indeterminate evidence; completed is authoritative commitment evidence. Matching completed always dominates unknown regardless of arrival order. Success-then-timeout: completed persists, late unknown is no-op. Timeout-then-success: unknown stored, later matching completed upgrades. Each write carries outcome class and reservation tuple match; tuple mismatch is quarantined, not merged. Existing skills Monotonic settlement for concurrent durable-op retries and Binding-matched monotonic operation settlement already cover this pattern; no new skill warranted.

When two retries share one durable operation record, one attempt may observe a committed success while a sibling attempt later times out. If settlement uses naive last-write-wins on a single status field, the late timeout write can overwrite completed with unknown, erasing proof of success. The design question is how to settle per-attempt outcomes without regressing a terminal success, and how both completion orders (success-first vs timeout-first) should behave.