fix(cache): serve cached entries only to the file they came from

[anoop-narang]

After a process has read 65,536 distinct parquet files, the next file is served the first file's cached data.

Why

A cache key keeps only 16 bits of the file id, but file ids come from a counter that only climbs (register_or_get_file). File 65,537 gets id 65536, which narrows to 0, so its keys are the first file's keys. Its reads then return the first file's arrays: wrong rows if the column types match, a panic in RecordBatch::try_new if they don't. The only guard is a debug_assert!, so release builds hit this silently.

Repro

files_whose_keys_collide_do_not_share_entries caches a batch for one file, registers 65,535 more, and reads the same batch through the 65,537th. On main it fails in release with "a file was served another file's cached data" (in debug, at the debug_assert!).

Fix

Keep the full file id with every cached entry and check it on every read. A mismatch is a cache miss, so the reader falls back to parquet. A write replaces whatever held the key.

• Memory: each index slot stores the file id next to the entry.
• Disk: each object gets an 8-byte file-id trailer, and the disk budget counts it. Disk keys don't change, so a late eviction or flush that overwrites a newer file's object just causes a miss for that file.

The key stays 64 bits because congee supports only 8-byte keys.

API change

insert, get, eval_predicate, prefetch, try_read_liquid, contains, read_entry and eval_predicate_on_entry on LiquidCache take an identity: u64. Callers with unique keys can pass any constant (the README and examples pass 0).

Cost: 8 bytes per entry and per disk object, plus one comparison per read.

Tests

• New: the repro, plus core tests for memory and disk mismatches.
• test_cache_entry_id_new_panic_file_id required the debug_assert! panic. It is replaced by a test that file ids keep their low 16 bits.

Follow-ups

1. Replacing a disk entry (by hydration, or now by another file) doesn't release its disk budget. This predates this PR; I'll send a separate fix.
2. The file-id map keeps every file ever read. With this PR, ids can safely be reused, so the map can drop a file once none of its data is cached. That also stops two active files that share a 16-bit id from repeatedly evicting each other.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 93.83378% with 23 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@c946ea4). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
src/core/src/cache/core.rs	90.33%	10 Missing and 13 partials ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #526   +/-   ##
=======================================
  Coverage        ?   81.38%           
=======================================
  Files           ?       80           
  Lines           ?    13666           
  Branches        ?    13666           
=======================================
  Hits            ?    11122           
  Misses          ?     2216           
  Partials        ?      328           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[anoop-narang]

@XiangpengHao I am merging this as a fix as current main is giving wrong results on long running processes. Let me know your thoughts on this. There is more to be done to make liquidcache better for long running processes.

[XiangpengHao]

LGTM thank you @anoop-narang