Problem

Eviction's walk-period heuristic benches a tree for up to 100 passes after unproductive walks, regardless of whether that tree currently dominates the cache's clean, dirty, or update-byte usage. A benched tree keeps growing while starved of eviction passes.

Fix (as merged, 5ad9d39adf)

• __evict_btree_dominating_cache() now takes the eviction flags being targeted and only checks dominance for those dimensions (clean / dirty / updates), not just clean+updates.
• A benched tree is still walked if it dominates cache usage for a currently-targeted dimension, unless its walk period has saturated at WTI_EVICT_WALK_PERIOD_MAX (100) – that cap is the anti-spin protection the original risk section called for.
• The dirty dimension is excluded from the dominance check for a tree that is currently syncing (checkpointing), since its dirty pages can't be evicted regardless of size.
• The walk-period reset on an eviction-goal change now applies to all connection types, not just disaggregated – the original scope-limit to disagg was itself part of the starvation bug.
• New stats eviction_server_walk_dominating_cache / eviction_server_walk_dominating_cache_unproductive track how often the override fires and how often it queues nothing.
• test/suite/test_eviction06.py covers the dominant update-tree walk path.

Validation

Sys-perf perf-required run + a controlled A/B/C experiment on the one true regression candidate showed no real perf regression (see comments) – both suspect variants cleared at a per-metric noise floor of 8-18%.