test_open_concurrent_same_path closed each successful collection immediately inside its thread, releasing the LOCK file before later-starting threads attempted to lock. Those threads then legitimately acquired the freed lock, so the 'exactly one successful open' assertion became timing-dependent and flaked on fast runners (observed on macos-arm64 CI once open/close got faster).
Keep the successful collection open until every thread has tried, then close it before the cleanup open, so the test deterministically verifies that the exclusive lock rejects concurrent read-write opens.
lc285652
e298a8c63d