Task: remove the failing assert and vendor the change into release branch.

Why it's safe (from slack):

—

Can the user see the intermediate value?

No, on any path. The corrupted version sits directly below the correct covering update with the same txnid and same start/durable timestamps giving it a zero-length visibility window. RTS can't split the pair either - it decides on durable ts which they share. The only mongod paths that reach version cursors are the printRecordMetadata/printIndexEntryMetadata diagnostic log printers - worst case they log the duplicate.

Can it reach the stable table via the drain? It reaches the stable table's in-memory update chain - that's unavoidable with assert removal - but it never becomes durable. Reconciliation selects the newest visible update, so the correct version is always the page value.

Checkpoint / oplog / page log? No, no and no. Checkpoints and disagg deltas publish only reconciliation output (page value + HS records) and the corrupted version is in neither. Layered constituents are log=(enabled=false) and the MongoDB oplog is written above WT.

History store? No - double-squashed: same-txn/same-start-ts duplicates are skipped both at HS chain collection and again at flush. Empirical confirmation: after checkpoint + forced eviction, persisted state was [correct @ disk, base @ HS], corrupted version gone and the cache_hs_write_squash stat ticked exactly once for it. Six runs across three shapes, zero failures, no other assert fired anywhere downstream.