refactor(memory-pool): drain the table in cleanup_all instead of cloning keys

[phil-opp]

Issue

MemoryPoolManager::cleanup_all collected every MemoryPoolId key into a throwaway Vec (cloning two Strings per entry) only to look each id back up and remove it one at a time:

let ids: Vec<MemoryPoolId> = table.keys().cloned().collect();
...
for id in &ids {
    if let Some(entry) = table.remove(id) ...
}

Fix

Replace that with a single std::mem::take(&mut *table) move and iterate the drained map directly, dropping the key clones and the redundant per-id re-lookup.

Behavior is unchanged:

• the guard is still held for the whole function (free_shared_memory never re-enters the table, so this can't deadlock — the original relied on the same fact);
• the table still ends empty;
• the unreleased_count / released_count accounting is identical.

Validation

• cargo clippy -p dora-memory-pool --all-targets -- -D warnings clean.
• cargo test -p dora-memory-pool --lib → 9 passed, including cleanup_all_tracks_counts and cleanup_all_reports_partial_release_on_failure.

---

⚠️ This PR is machine-generated by Claude (an AI assistant) as part of an automated code-review run, and was verified against current origin/main. Please review carefully before merging.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TMv79fayzGF9mDV7vPMQN7

---

Generated by Claude Code

[trunk-io]

😎 Merged successfully - details.

[phil-opp]

🤖 Automated review by Claude — fully automated, no human in the loop.

The std::mem::take(&mut *table) drain in cleanup_all is behavior-equivalent to the previous clone-keys-then-remove loop: the lock guard is held for the same window, unreleased_count is unchanged (drained.len() == prior ids.len()), the table still ends empty, and free_shared_memory does not re-enter the table (it was already called under the same guard in the old code, so a re-entrant access would have deadlocked before). Avoids the per-entry key clones. No issues found.

---

Generated by Claude Code