[Backport][main to 0.9] | feat(cache): make FileCachePool thread-safe for multi-vCPU access (#1555)

[photonlibos]

feat(cache): make FileCachePool thread-safe for multi-vCPU access (#1555)

• feat(cache): make FileCachePool thread-safe for multi-vCPU access

Guard all FileCachePool metadata (fileIndex_, lru_, cold tiers, totalUsed_,
tuning state) with a coarse photon::mutex (m_lock_) so one pool can be shared
across multiple photon vCPUs (OS threads).

Invariants:

• m_lock_ is held only across in-memory ops; never across open()/do_open() or
  forceRecycle()/eviction(), keeping the lock order rw_lock -> m_lock_ one-way
  (avoids ABBA with ObjectCache's per-item mutex and non-reentrant self-deadlock).
• eviction/evict snapshot a victim under m_lock_, release it, do the I/O
  (open()+WLOCK truncate), then re-lock to finalize.
• the write path accounts size under the store rw_lock (updateSpace fstats under
  m_lock_) so it can't drift against eviction's WLOCK+truncate; forceRecycle()
  is deferred to do_pwritev2 after rw_lock is released.
• running_/exit_/isFull_ and LruEntry::truncate_done become std::atomic.

Add a multi-vCPU concurrency stress test (CachePool.concurrent_stress).

QuotaFilePool is left unchanged and documented as not-yet-thread-safe (it is
currently unwired: the factory always builds a plain FileCachePool).

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

• check total used in eviction loop

---

Co-authored-by: Claude Opus 4.8 noreply@anthropic.com
Generated by Backport Auto PR, by cherry-pick related commits.

Please review and decide whether to merge or close this backport PR.

Conflicts

Cherry-pick produced conflicts. Conflict markers are committed as-is; please resolve them manually before merging.

• eef65fb: fs/cache/full_file_cache/cache_store.cpp