refactor: simplify task-shared pool guard after review

Cleanups from a quality pass over the previous commit, no behaviour change
except where noted:

- Use `parking_lot::Mutex` for TASK_SHARED_MEMORY_POOLS instead of hand-rolled
  `PoisonError` recovery over `std::sync::Mutex`. parking_lot never poisons, is
  already a direct dependency, and is what the sibling THREAD_MEMORY_POOLS
  registry and fair_pool.rs in this same module already use. Removes the
  `lock_pools` helper and its rationale comment.
- Delete `MemoryPoolType::is_task_shared` and the `debug_assert` that was its
  only remaining caller. Task-sharedness is now encoded solely by which
  `create_memory_pool` arms return a guard, so the predicate was a second source
  of truth reconciled only by an assertion that compiles out in release builds.
  This also drops `TaskSharedPoolRef::pool_type`, which existed only to name the
  pool type in one warning, and with it the `Debug` derive on MemoryPoolType.
- Collapse the four repeated destructure-and-rewrap task-shared arms of
  `create_memory_pool` behind a local `task_shared` helper paired with the
  existing `tracked` helper, so `Some(pool_ref)` appears once.
- Use the `Entry` API in `TaskSharedPoolRef::drop` so the release path hashes the
  key once rather than for both `get_mut` and `remove`.
- Drop the raw-pointer round trip through `get_execution_context`'s `&mut` in
  `releasePlan`; cast straight to `*mut ExecutionContext` for `Box::from_raw`.
- State the concrete consequence of the `_task_shared_pool_ref` field ordering
  (a later plan in the same task would get a second full-budget pool) rather than
  just asserting that the ordering matters.

Behaviour change: `CometExecIterator.close` now releases the native plan even
when an earlier teardown step throws. Setting `closed` first removed the
double-release hazard but made any throw from `currentBatch.close()`,
`nativeUtil.close()` or a shuffle block iterator skip `releasePlan` entirely,
which strands the very context this change set out to free. The teardown failure
is still propagated, with a release failure attached as a suppressed exception.