Add story handle caching to ChronoKVS

[EnekoGonzalez3]

Summary

Implements story handle caching in ChronoKVS to dramatically improve write performance by avoiding repeated AcquireStory/ReleaseStory RPC calls.

Key Feature: Adds a flush() API to explicitly commit cached handles when needed.

Changes

Core Implementation

• Add handleCache (std::unordered_map<std::string, chronolog::StoryHandle*>) to store active handles by key
• Add cacheMutex for thread-safe cache access
• Add getOrAcquireHandle() helper for lazy handle acquisition (cache hit/miss pattern)
• Add flushCachedHandle() to release a specific key's handle before read operations
• Add public flush() method to release all cached handles and commit pending writes

Behavior

• storeEvent(): Uses cached handles for fast repeated writes to the same key
• retrieveEvents(): Automatically flushes the key's cached handle before reading (ensures data consistency)
• Destructor: Releases all cached handles before disconnecting

API Usage

ChronoKVS kvs;

// Write operations use cached handles (fast)
kvs.put("key1", "value1");  // Acquires handle, caches it
kvs.put("key1", "value2");  // Reuses cached handle
kvs.put("key1", "value3");  // Reuses cached handle

// Option 1: Explicit flush before waiting for propagation
kvs.flush();  // Releases all cached handles, commits data
// ... wait for data propagation ...
auto history = kvs.get_history("key1");  // Works correctly

// Option 2: Read methods auto-flush (no explicit flush needed)
auto value = kvs.get("key1", timestamp);  // Auto-flushes key1's handle first

Performance Impact

Before: Each operation required AcquireStory + operation + ReleaseStory (3 RPC calls)
After: First operation acquires handle, subsequent operations reuse cached handle

Scenario	Before	After	Improvement
1000 puts to same key	1000 acquire/release cycles	1 acquire + 1000 logs + 1 release	~160x faster
Measured throughput	~27 ops/sec	~3000+ ops/sec	~111x faster

Important Notes

• ChronoLog Data Propagation: After releasing a story handle, ChronoLog requires time to propagate data before it becomes available for replay. Applications should call flush() and wait before reading recently written data.
• Thread Safety: All cache operations are protected by mutex for safe concurrent access.
• Automatic Consistency: Read operations (retrieveEvents) automatically flush the relevant key's cached handle to ensure data consistency.

Testing

All 6 integration tests pass:

• ✓ Put operations (with caching)
• ✓ Get by timestamp
• ✓ Get history
• ✓ Get range
• ✓ Get earliest
• ✓ Get latest

Closes #431

[fkengun]

I don't think we need these two new header files. Maybe they were added for already deleted codes?