While investigating [BF-46626], I noticed WiredTiger error-level log messages at WT_CONNECTION.close that report a non-empty cache. The close completes without any failure, but the messages appear to indicate a real accounting bug.

Observed log messages (session WT_CONNECTION.close, logged via the WT event handler with error: 0):

__wt_cache_destroy(...):268:cache server: exiting with 75257811 image bytes in memory
__wt_cache_destroy(...):271:cache server: exiting with 75257811 bytes in memory
__wt_cache_destroy(...):292:cache server: exiting with 1230687 scrub image bytes and 50 scrub image pages

Why this looks like a bug:

__wt_cache_destroy (src/cache/cache.c) says:

/* The cache should be empty at this point.  Complain if not. */

and for the scrub counters:

Every page has been discarded and every dhandle closed by this point, so any
image checkpoint scrub retained has been freed with its page. A non-zero count
means a path freed an image without releasing its accounting.

So per the code's own comment, a non-zero scrub-image count means some path freed an image without releasing its accounting.

Notes:

• The dirty checks (bytes_dirty, pages_dirty) did not fire, and pages_inmem == pages_evicted. This appears to be accounting only - no durability or memory-leak concern.
• The scrub-image counters were added recently with the checkpoint scrub-eviction work (WT-16973 / WT-18005), so the missing decrement may be in one of the new paths (possibly disagg/layered-specific, since this was observed in disagg suites).
• Because the check logs at ERROR level but never fails, these messages pollute CI logs and confuse failure triage, while nothing tracks them. If firing is considered benign/expected, the severity or wording may be worth revisiting.

Where seen:

• [BF-46626] - disagg_sharded_colls_jscore_passthrough, 2026-09-29.
• The same messages appear in several other disagg passthrough CleanEveryN failure logs from the same week.