Cache goes stuck in async step-down while a step-down checkpoint is still running.

Shape of the failure:* An async step-down is in flight and the step-down checkpoint takes a very long time to complete (minutes, not seconds).

• For the whole duration of that checkpoint, the cache fills and eviction cannot make forward progress: application threads end up in cache-full waits and the workload stalls, in some runs until the cache-stuck timeout fires.
• Symptoms match the cache full: no family of stalls in WT-18253 - the aggregate clean/dirty/updates checks look satisfiable, but the pages eviction actually walks are not evictable, so eviction spins without freeing bytes.

Suspected contributors (to be confirmed from a captured run):

• Content written by the drain / ingest side during the step-down window is pinned by the running checkpoint and by the pinned timestamp in force during the follower window, so the dirty bytes accumulated cannot be written out until the checkpoint finishes.
• The longer the step-down checkpoint runs, the more unevictable content accumulates, so this is self-reinforcing: a slow checkpoint makes the cache pressure worse, and cache pressure makes the checkpoint slower.

What we want out of this ticket:

• A cache dump plus eviction statistics from a run that hits the stall, so we can attribute the unevictable bytes to a specific tree / handle set (ingest vs. stable vs. shared history store).
• Understand why the step-down checkpoint runs as long as it does, and whether the step-down path should bound it or let eviction make progress alongside it.
• Fix, or explicitly document, the interaction so a long step-down checkpoint cannot wedge the cache.

Logs / cache dump: to be attached once a run is captured.