Follow-up to WT-18085 (PR https://github.com/wiredtiger/wiredtiger/pull/14408).

WT-18085 showed that a non-precise ("fuzzy") checkpoint can write a leaf page before a later eviction moves that page's older versions into the history store, and then capture those history store records in the same checkpoint. The two files are not a snapshot of a single point in time, so __verify_key_hs comparing history store records against the data store's page image reports overlaps between versions that never coexisted.

The fix gates that comparison on WT_CONN_PRECISE_CHECKPOINT, keeping the ordering check among the history store records themselves running in all cases.

The gap

The flag reflects the verifying connection's current setting, not the one in effect when the checkpoint was written. A database whose checkpoints were written without precise checkpoints, reopened by a connection that enables them, is still exposed. Demonstrated on the WT-18085 artifact, which was produced with precise_checkpoint=0:

../../wt -h <copy> verify file:T00003.wt                           # clean
../../wt -C "precise_checkpoint=true" -h <copy> verify file:...    # reports the overlap

What was considered

• Persist the setting per checkpoint. Sound, but a metadata change for a narrow case.
• Derive it. A precise checkpoint writes nothing above its checkpoint timestamp, so content above it would imply a fuzzy checkpoint. This does not work: in the WT-18085 artifact everything is below stable (max durable timestamp 771531 vs stable 771534), so the heuristic classifies that fuzzy checkpoint as precise and the check fires anyway.

Why it was left

The exposure is transient - the skew survives only until the pages involved are reconciled again, or the stale history store records fall below oldest and are cleaned up. It requires a verify on a connection that has turned precise checkpoints on, over checkpoints written before the switch, inside that window. Currently recorded as a FIXME in __verify_key_hs.