Alex raised in WT-16084 that being able to emit a delta directly, without paying the full cost of reconciliation, would reduce reconciliation overhead for pages that are repeatedly modified in small ways. WT-16707 prototyped this and got a working version, but was closed Won't Fix – the complexity was too high relative to the benefit.

Note the walk over the page's updates is unavoidable either way – reconciliation must visit every entry to determine visibility and content regardless of whether a delta or a full image is produced. What a fast path would actually save is the image-construction step: building the new on-disk page image (the memory copy/serialization work), skipped only if we're confident a delta is the correct output before doing it.

The blocker is knowing that in advance:

• Eviction reconciliation can't take this shortcut in the general case. Update-restore decisions come out of the same per-key walk that would decide delta-vs-full, so there's no point at which the answer is known early enough to skip work – the walk still has to happen, and by the time it's done there's nothing left to save.
• Checkpoint reconciliation doesn't do update-restore, so it's the more plausible target. Its blocker is narrower: today a page that splits can't be represented as a delta at all (that's WT-15709's scope), so committing to the delta path early and being wrong about a split has no fallback.

This ticket should follow WT-15709 (support generating page deltas for page splits). Once split pages can produce deltas too, the checkpoint fast path no longer needs to predict split-vs-not-split – it can commit to the delta path unconditionally and let either outcome be representable, which removes the hard part of this ticket rather than just working around it. The remaining benefit is avoiding image construction, not avoiding the update walk itself, so this should be scoped and evaluated with that smaller benefit in mind.