Unify the mutex lock-poisoning policy

Lock-poisoning tolerance is scattered across 5 crates and 12+ sites with inconsistent behavior — some log (`orchestrator.rs:452` documents its `unwrap_or_else(PoisonError::into_inner)`), some are fully silent. Worst case: `agent-core/src/hook_runtime.rs` (~161, also 149/194/288) does `hooks.read().ok()` — after a panic while holding the lock, every button binding silently stops working for the life of the agent.

Options, in preference order:

1. `parking_lot` (no poisoning semantics, already in the dependency graph via gpui) — also lighter in the hook's hot path. Watch the gpui/gpui-component lock pins when adding the direct dependency.
2. A single shared helper encoding one policy (`PoisonError::into_inner` + one warn), replacing all ad-hoc sites.

Surfaced by the standards audit behind #381.

Start by auditing the lock sites across the five crates, beginning with orchestrator.rs:452 and agent-core/src/hook_runtime.rs at approximately lines 149, 161, 194, and 288. Compare the documented unwrap_or_else(PoisonError::into_inner) behavior with the silent hooks.read().ok() path. Done means all 12+ sites follow one documented poisoning policy and hook bindings no longer silently stop after a panic.

Written by the indexing model from the issue text.