[fix](test) Wait for the meta-store write to land, not just leave the queue

FSFileCacheLeakCleanerTest's add_metadata_entry() waited for the meta store's
write queue to drain as its "async write completed" barrier. But the async
worker dequeues an operation *before* it issues the rocksdb Put, so an empty
queue only proves the write is in flight, not that it is readable. If
run_leak_cleanup() runs inside that window, approximate_entry_count() (which
iterates rocksdb only, by design) sees zero metadata blocks and skips the
cleanup entirely -- remove_orphan_and_tmp_files then finds its orphan and tmp
files still on disk.

The window is a few statements wide and never fired in per-file CI builds;
the unity-batched IO objects shifted thread timing on the ASAN pipeline and
hit it on the first round. Poll the store itself (get() reads only rocksdb,
the same source approximate_entry_count() counts) instead of the queue size.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gdfkk7RqgD5e3Uv7bTM3NV

Author: morningman

be/test/io/cache/fs_file_cache_storage_leak_cleaner_test.cpp

@@ -131,8 +131,10 @@ class FSFileCacheLeakCleanerTest : public BlockFileCacheTest {
             BlockMetaKey mkey(0, hash, offset);
             BlockMeta meta(FileCacheType::NORMAL, 16, 0);
             storage._meta_store->put(mkey, meta);
-            // Wait for async write to complete for test stability
-            for (int i = 0; i < 100 && storage._meta_store->get_write_queue_size() > 0; ++i) {
+            // The async worker dequeues an operation before it lands in rocksdb,
+            // so an empty write queue does not mean the entry is readable yet.
+            // Poll the store itself: leak-scan decisions count rocksdb contents.
+            for (int i = 0; i < 100 && !storage._meta_store->get(mkey).has_value(); ++i) {
                 std::this_thread::sleep_for(std::chrono::milliseconds(50));
             }
         }