refactor(blockdb): use atomic.Bool for cacheDB closed state

[DracoLi]

Why this should be merged

This cleans up the cacheDB close logic by removing an unnecessary mutex and using an atomic.Bool instead, which makes the code simpler and cheaper to reason about while preserving the same behavior on close.

This PR is a follow up to this comment in #4425.

How this works

cacheDB now tracks the closed state via an atomic.Bool rather than closeMu. We still rely on the underlying DB’s own synchronization to protect any in-flight disk I/O; the cache itself doesn’t need extra protection at close.
If a Get races with Close, the cache lookup will fail and the underlying DB will return a “db closed” error as expected.

How this was tested

Unit tests

Need to be documented in RELEASES.md?

No, internal implementation detail only

[Copilot]

Pull Request Overview

Refactors the cacheDB implementation to use atomic.Bool instead of a mutex-protected boolean for tracking closed state, simplifying the synchronization logic while maintaining the same thread-safety guarantees.

Key Changes:

• Replaced sync.RWMutex and boolean field with atomic.Bool for closed state tracking
• Updated all methods to use atomic operations instead of mutex locks
• Simplified Close() method to use CompareAndSwap for idempotent close behavior

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[rrazvan1]

If a Get races with Close, the cache lookup will fail and the underlying DB will return a “db closed” error as expected.

But if the cache has that value, the value will be returned, even though the db is closed.
Is this an issue?

[DracoLi]

But if the cache has that value, the value will be returned, even though the db is closed.
Is this an issue?

Not an issue here.