On a non-forced WT_SESSION::drop of a file, __drop_file calls __wt_conn_dhandle_close_all inside WT_WITH_HANDLE_LIST_WRITE_LOCK. With mark_dead=false and a clean tree, __wt_conn_dhandle_close -> __wt_checkpoint_close -> __wt_evict_file(WT_SYNC_DISCARD) walks and frees every in-cache page of the tree synchronously, while the caller holds the schema lock, table write lock and dhandle-list write lock. A forced drop instead marks the handle dead and defers the discard to the sweep server. Same code structure on develop.

While the write lock is held:

• Any operation needing to acquire/open a dhandle blocks.
• Eviction stops entirely: the eviction server's walk takes the dhandle-list read lock (__evict_walk, src/evict/evict_lru.c).

Since SERVER-74033 stopped passing force=true, every replicated ident drop takes this path. Evidence from HELP-97809 (371 GB cache, drop of a ~700 GB database): single-ident discards held the locks for 16 - 70 s, eviction worker throughput dropped from ~10k pages/s to ~0 with >90% CPU idle, FTDC stalled, connections spiked to 17.8k and the primary was eventually fasserted during a stepdown attempt. Discard cost is further amplified by WT-18425 (__gen_oldest scans the session array on every page free; sessions spiked to 3 - 7k).

Proposal (to be evaluated):

• After writing the final checkpoint, mark the handle dead and defer the cache discard to the sweep server (as forced drop does)
• Or evict the tree before taking the dhandle-list write lock.