After ShardingCatalogManager::clearJumboFlag or splitOrMarkJumbo toggles a chunk's jumbo flag, the balancer can continue to observe the old value indefinitely. Both paths patch the in-memory ChunkInfo in the configsvr's RoutingInformationCache and then write the new value to config.chunks, but neither write bumps the chunk's placement version. The reasoning behind not bumping the chunk's placement version is detailed in SERVER-125661.

The problem is that the in-memory ChunkInfo is patched before persisting the new value:
1. Take _kChunkOpLock.
2. Update the in-memory ChunkInfo.
3. Persist the new jumbo value to config.chunks.

If a routing-cache rebuild happens between steps 2 and 3 (e.g. due to an invalidation or eviction), the rebuild reads the stale on-disk value into a brand new ChunkInfo, discarding the in-memory patch. Because no subsequent event bumps the chunk's placement version, the cache's incremental-refresh keeps reusing that stale ChunkInfo, and the balancer never sees the new jumbo value until something else bumps the version.