fix(common): add cleanup for stale file locks to prevent memory leak

[echobt]

Summary

Fixes #5145 and #5142 - File lock HashMaps grow without bound.

Problem

Lock entries accumulate forever without cleanup.

Solution

Added stale lock cleanup mechanism to release old entries.

[greptile-apps]

Greptile Overview

Greptile Summary

This PR addresses memory leaks caused by unbounded growth of file lock HashMaps by implementing automatic cleanup of stale lock entries.

Key Changes:

• Added MAX_LOCK_ENTRIES constant (10,000) as cleanup threshold in both file_locking.rs and session_store.rs
• Implemented cleanup_stale_entries() using Arc reference counting to identify and remove unused locks
• Cleanup automatically triggers when HashMap size reaches the threshold
• Added public cleanup() and lock_count() methods to FileLockManager for manual maintenance

Implementation Approach:
The cleanup mechanism leverages Arc::strong_count() to detect stale entries - when only the HashMap holds a reference (count == 1), the lock is no longer in use and can be safely removed. This is a sound approach that prevents memory leaks without breaking existing lock holders.

Confidence Score: 4/5

• This PR is safe to merge with proper testing of the cleanup mechanism
• The implementation correctly uses Arc reference counting for cleanup and is thread-safe. The threshold-based approach (10,000 entries) is reasonable. However, no tests were added for the new cleanup functionality, and the choice of threshold is not documented with justification
• Both files should have tests added to verify cleanup behavior under load

Important Files Changed

Filename	Overview
src/cortex-common/src/file_locking.rs	Added automatic cleanup of stale lock entries using Arc reference counting, triggered at 10,000 entries
src/cortex-resume/src/session_store.rs	Added same stale lock cleanup mechanism to session store's file lock manager

Sequence Diagram

sequenceDiagram
    participant Caller
    participant FileLockManager
    participant HashMap
    participant Arc
    
    Caller->>FileLockManager: get_lock(path)
    FileLockManager->>HashMap: lock().unwrap()
    HashMap-->>FileLockManager: MutexGuard<HashMap>
    
    alt locks.len() >= MAX_LOCK_ENTRIES (10,000)
        FileLockManager->>FileLockManager: cleanup_stale_entries(&mut locks)
        loop For each entry in HashMap
            FileLockManager->>Arc: strong_count(arc)
            Arc-->>FileLockManager: count
            alt count == 1
                FileLockManager->>HashMap: remove entry (stale)
            else count > 1
                FileLockManager->>HashMap: keep entry (in use)
            end
        end
    end
    
    FileLockManager->>HashMap: entry(path).or_insert_with(...)
    HashMap-->>FileLockManager: Arc<Mutex<()>>
    FileLockManager->>Arc: clone()
    Arc-->>FileLockManager: Arc<Mutex<()>> (incremented count)
    FileLockManager-->>Caller: Arc<Mutex<()>>
    
    Note over Caller,Arc: Caller uses lock for operations
    
    Caller->>Caller: drop Arc reference
    Note over Arc: strong_count decrements
    
    alt Last external reference dropped
        Note over HashMap: Entry becomes stale (count == 1)
        Note over HashMap: Will be cleaned up when threshold reached
    end

Loading

[greptile-apps]

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Consider adding a test that creates >10,000 lock entries and verifies cleanup behavior

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/cortex-common/src/file_locking.rs
Line: 604:608

Comment:
Consider adding a test that creates >10,000 lock entries and verifies cleanup behavior

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

How can I resolve this? If you propose a fix, please make it concise.

[echobt]

Consolidated into #80 - fix: consolidated memory and storage improvements