Fix UAF when iterator outlives DB during shutdown

[Deepmalya1]

FIXES #1292

Problem

Iterators created by DBImpl::NewInternalIterator register a cleanup callback that may execute after the owning DBImpl instance has been destroyed. The cleanup path previously relied on a mutex whose lifetime was tied to the DBImpl object. If the DB was destroyed before all iterators were released (for example, during shutdown races in multi-threaded environments), iterator destruction could access freed memory, resulting in a use-after-free and segmentation fault in release builds.

Fix

This change introduces a minimal internal lifetime indirection so that iterator cleanup no longer depends on a mutex that may already have been destroyed. The mutex lifetime is safely extended for the duration of iterator cleanup, preventing access to freed memory. The fix is internal-only, does not modify the public API, and preserves existing semantics for correct usage.

Behavior Change

• Before: Destroying a DB before its iterators could result in a segmentation fault or ASAN-reported heap-use-after-free during iterator cleanup.

• After: This change removes undefined behavior during iterator cleanup; incorrect shutdown order may still trigger existing internal assertions, consistent with documented usage requirements.

Correct usage (destroying iterators before the DB) is unaffected.

Testing

The issue was validated using a minimal external reproducer that consistently triggered a crash on the current main branch and no longer does so after this change. The shutdown-order race involved is difficult to cover deterministically in the existing test framework, so no new internal test was added.

Notes

• Internal implementation change only
• No public API changes
• No build system or configuration changes
• Addresses a critical memory-safety issue
• CLA has been signed