[Bug]: ECExampleConnector.has_cache_item() creates empty hash directories in shared storage on cache-miss lookups

Finding: In an external report on vLLM (reporter cites v0.30.0 and says the same code is on main), ECExampleConnector.has_cache_item() is said to create an empty per-hash directory in shared EC storage whenever a lookup misses. Source: https://github.com/vllm-project/vllm/issues/60820 Reported mechanism: the reporter says has_cache_item() calls _found_match_for_mm_data(), which calls _generate_filename_debug(). That function calls _generate_foldername_debug() with its default create_folder=True, so the folder is created before os.path.exists() checks for encoder_cache.safetensors. The reporter notes the docstring documents the auto-creation, so this is a design side effect on the lookup path, not a crash. No error message is reported (https://github.com/vllm-project/vllm/issues/60820). Reported call sites: the scheduler's encoder-input admission check (_try_schedule_encoder_inputs) and update_state_after_alloc() on consumer instances (https://github.com/vllm-project/vllm/issues/60820). The reporter infers that every probed-and-missed image hash leaves an empty directory. Observation: after one cache-miss probe on an A100 EPD testbed, the shared EC directory held an empty hash directory with no safetensors file next to a real populated entry (https://github.com/vllm-project/vllm/issues/60820). This is a single observation by the reporter. Reporter-inferred impact: unbounded growth of empty directories, ambiguity when listing the cache root (cached vs. merely probed), pollution of directory-listing-based tooling or GC, and metadata writes on network filesystems. These were not measured in the report. Status: the reporter proposes keeping folder creation on the write path (save_caches) and passing create_folder=False on the lookup path, and says a PR with a unit test will follow. At capture time the issue is open with no maintainer response, no linked PR, no fix commit and no released fix in the supplied material. Limitations: this is an external report only. It is not reproduced by KFA, and the cause has not been confirmed by a maintainer. The affected version range is unknown beyond the reporter's v0.30.0 and main claims. Treat the proposed patch as an unverified suggestion.