fix(plugins): stop the hook slot from latching off for the life of the process

[deadczarvc]

Problem

The hook enforcement layer can latch itself off for the life of the process.

1. _run_callback_with_timeout waits timeout for the worker; on expiry it logs, records
   _hook_timeout_suppressed_until[callback_key] and returns without freeing the slot.
   The abandoned worker never reaches _release_token, so callback_key stays in
   _hook_running_callbacks forever. Every later call of that hook fails closed — not for the
   suppression window, but until the process restarts.
2. The running/suppression key is (hook_name, id(cb)) — it ignores the tool. A slow shell
   hook that fired for tool A therefore rejects unrelated tool B whose own matcher never ran.

Observed in the field: one stalled callback produced 459 hook skips and 15 blocked tool
calls over 2 hours, including calls that never matched the stalled hook's own matcher.

Repro (hermetic)

tests/hermes_cli/test_plugins.py::test_slow_hook_for_one_tool_does_not_block_an_unrelated_tool
registers a hook that never returns for one tool and asserts an unrelated tool still passes.

Fix

• free the slot on the timeout path (_release_token(callback_key)) so the latch is bounded by
  the suppression window instead of the process lifetime;
• scope the key by tool_name for tool-bearing events (tool-less events keep the old key).

Fail-closed behaviour and "same tool does not run two workers" are preserved.

Verification

• new regression test passes; existing tests/hermes_cli/test_plugins.py suite passes;
• live environment, after backend restart: 0 blocked tool calls and 0 skips in the
  observation window, against 478/hour before the fix;
• a separate invariant check now asserts that a shell hook's own timeout is strictly below
  plugins.hook_callback_timeout, so the abandoned-worker path is not reachable in normal
  operation (our_max * 1.2 <= kernel, with threaded path disabled as an explicit escape).

[deadczarvc]

Related, already merged upstream: #94339 (un-invert the stdio children liveness check) fixed the polarity half of the same family, and #96452 salvaged the reconnect-on-fast-fail half of our previous report #95626 (our commit was cherry-picked there with authorship preserved).

This PR is the next defect in that same lifecycle: the hook enforcement layer latches itself off. Unlike the MCP path, here the abandoned worker never releases its slot, so the first timeout poisons every later call of that hook for the life of the process — including tools whose matcher never ran.

Both halves are covered by a regression test; the invariant check (our hook timeout * 1.2 <= kernel timeout) is stated in the body because it makes the abandoned-worker path unreachable in normal operation.

[deadczarvc]

Closing as superseded by upstream work.

The latch half is fixed in main: _release_token() now clears the running slot and _hook_abandoned tracks a timed-out worker, so one stalled callback no longer latches "still running" for the life of the process (see fix(plugins): keep one worker per callback while a timed-out worker is still running).

The scoping half is covered too, by a different mechanism: the gate key is now (hook, callback, _hook_call_identity(kwargs)), where the identity is the tool_call_id (falling back to turn_id). Two concurrent calls — including calls of different tools — no longer collapse into one key, which is the outcome this PR argued for; the per-tool-name key I proposed is a narrower variant of the same idea.

Thanks for landing it. I am closing this PR rather than rebasing a narrower duplicate.