fix(simulation): store uploaded shards the way CAS does for LocalClient

[sirahd]

The simulation rebuilt each uploaded shard through MDBInMemoryShard, while CAS re-serializes through the streaming serializer and keys the object by the hash of those bytes. Only the streaming path stamps shard_creation_timestamp, so identical content collapsed onto a single hash forever in the simulation but not in production. That let a re-upload land back on a hash GC had already deregistered from the global dedup table and still had queued for deletion, leaving dedup rows pointing at a condemned shard — stress_test_high_fp failed on it 7 runs out of 7.

Two consequences of storing what CAS stores:

• shards carry no lookup tables, so get_file_chunk_hashes reads its file entry from the authoritative table, as the reconstruction path already did
• they record a zero key expiry, so this server-side store is no longer scanned on open as if it were a client cache — that scan prunes by exactly that field

Test plan: full GC stress suite against this branch with no GC-side change, all three variants green and integrity=36ok/0FAIL each (stress_test_high_fp 14/14 epochs, stress_test, stress_test_convergence), at unchanged throughput and unchanged collection rates.

---

Note

Medium Risk
Changes simulation shard hashing, on-disk layout, and file lookup paths that GC stress tests depend on; behavior is intentional parity with CAS but affects dedup/GC edge cases in tests only.

Overview
Aligns simulation LocalClient shard persistence with production CAS so GC stress tests match real dedup/GC behavior.

Shard uploads no longer rebuild via MDBInMemoryShard; validated input is re-serialized through the streaming path (HashedWrite + minimal_shard.serialize), keyed by the hash of those bytes (client-supplied hash ignored), written atomically via temp file + rename. Identical logical content therefore gets a new shard hash when the footer stamps a creation timestamp—fixing cases where re-upload reused a hash already deregistered/queued for deletion while dedup rows still pointed at it.

Shard manager init disables directory scan on open (scan: false) because CAS-form shards use zero key expiry; scanning would incorrectly prune them as if this were an expiring client cache.

get_file_chunk_hashes resolves file metadata from FILE_TO_SHARD_TABLE (get_file_info_from_table) instead of shard-manager reconstruction lookup, consistent with shards stored without embedded lookup tables.

^{Reviewed by Cursor Bugbot for commit 5cec0e0. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 81a3295. Configure here.}