fix: prevent blocking operations from freezing shard threads

[kacy]

summary

• adds a dedicated background OS thread (ember-drop) for deferring expensive value deallocations off the shard hot path
• introduces UNLINK command — semantically identical to DEL but always defers the destructor to the background thread
• extends FLUSHDB to accept an optional ASYNC argument that swaps the entries map instantly and defers bulk deallocation
• existing DEL, eviction (try_evict), and lazy expiration (remove_if_expired) now automatically defer large value drops when the drop handle is present (values with >64 collection elements)
• adds a warning log when KEYS is called on keyspaces with >10k keys

what was tested

• all 720+ existing tests pass across the workspace (cargo test --workspace)
• new unit tests for dropper (defer small/large values, defer entries, empty entries skip)
• new unit tests for is_large_value threshold behavior (strings, lists, hashes, sets)
• new protocol tests for UNLINK (single, multi, no args) and FLUSHDB ASYNC (with/without, case insensitive)
• cargo clippy --workspace — zero warnings
• cargo fmt --check — clean

design considerations

• OS thread, not tokio task: dropping large data structures is CPU-bound work that would starve the async executor. a plain std::thread avoids this entirely.
• bounded channel with try_send fallback: the 4096-capacity SyncSender ensures the shard never blocks waiting for the drop thread. if backpressure hits, we just drop inline — graceful degradation, not a hard failure.
• memory tracker updated immediately: when a key is unlinked, memory usage is decremented before the value is sent to the background thread. this is correct because the keyspace no longer references the data, and it prevents the memory limit from being stale.
• UNLINK maps to AofRecord::Del: on replay, the deallocation strategy doesn't matter — only the fact that the key was removed. reusing the existing Del record avoids adding a new record type.
• concurrent mode ignores async_mode: DashMap doesn't have the same blocking issue as shard channels, so both DEL and UNLINK use the same keyspace.del() path. FLUSHDB ASYNC calls clear() directly since there's no drop handle in concurrent mode.