Evict stale and excess lock snapshots [minor]

[matt-edmondson]

Fixes #50

Summary

LockSnapshotStore kept one snapshot per (upstream, repository, ref) for as long as the process ran. The ref comes from the client's ?refspec=, so every branch anyone had listed kept a full lock list in memory, and a client could grow the store without limit.

The store now evicts on every Publish. Publishing is the only thing that grows it, and it follows a full upstream walk, so the O(n) scan costs little by comparison:

1. It drops snapshots older than Locks:ListTtl. These would be refetched before being served anyway.
2. It then drops the oldest remaining snapshots, by TakenAt, until at most Locks:MaxSnapshots are left. This is a new option, default 1000, and the validator rejects values of zero or less.
3. It never evicts the snapshot it has just published, even when that snapshot is already old because the walk took a long time.

Removal checks the value as well as the key, so a snapshot republished under the same key during the scan is not lost. Only eviction is serialised. Read and Invalidate still take no lock, and their behaviour is unchanged. In particular, LockFanOut can still resolve lock ids from a stale snapshot until the next publish, so a large batch unlock does not start doing more upstream walks. Worst-case memory is now MaxSnapshots × MaxSnapshotLocks.

TimeProvider is now passed into the store, which DI already registers. The README settings table documents Locks:MaxSnapshots.

Out of scope: normalising the refspec or repository path in the key. Whether a path is case-sensitive depends on the forge, so this is not a small change. It is also tied to the refspec-keyed design that #46 and #47 cover. The cap bounds memory either way.

How it was tested

New tests in GitLfsCache.Tests/Locks/LockSnapshotStoreTests.cs use FakeTimeProvider:

• Publish_AfterManyRefsHaveOutlivedTheListTtl_DropsEveryStaleSnapshot: publishes 200 distinct refspecs, advances time by ListTtl, then publishes once more. Afterwards the store holds only that last snapshot.
• Publish_BeyondMaxSnapshots_EvictsTheOldestFirst: with a cap of 3, publishes 5 snapshots. The 2 oldest are evicted.
• Publish_ASnapshotThatIsAlreadyOld_KeepsIt, Publish_RepublishingOneKey_HoldsOneSnapshot and Invalidate_DropsEveryRefOfTheRepositoryOnly check the guard and the existing behaviour.
• A validator test for MaxSnapshots <= 0.

Revert proof: with eviction short-circuited in LockSnapshotStore, the two eviction tests fail (352/354 pass). With the fix restored, all 354 pass.

Full suite: dotnet build finished with 0 warnings and 0 errors, and dotnet test passed 354 of 354.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K6bDUGMFsAQews3TnA2jXr

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud