Data: Stop hook fired 0/329 times on tool_use-terminated turn ends (measurement for the #29881 class)

Contributing a measurement to the class discussed in #29881 (closed as enhancement, thread locked) and #3113 — those threads had no hard numbers, and this seems like the kind of signal that helps prioritization.

Across a local corpus of 1,801 session transcripts (439 with observed Stop-hook activity; turn-ends counted only after the first observed Stop firing per transcript, so the hook is known-wired in every counted case):

• turn ended with text → Stop fired 7,150 · did not fire 1,555
• turn ended with tool_use (e.g. a turn whose last block is a tool call) → Stop fired 0 · did not fire 329

Within-session control (one long session, same wiring): 106 text-terminated turn-ends fired Stop; all 7 tool-terminated ends did not.

So on the current contract, when a turn ends on a tool call no blocking-capable hook is invoked at all — Stop is structurally absent on this class, not flaky. The docs read consistently with this (Stop = "when Claude finishes responding"; of the documented hook events only Stop/SubagentStop are blocking-capable at turn end, and no event means "turn about to end without producing text").

Practical impact: any supervision or automation built on Stop silently misses every tool-terminated turn end — which is exactly the "silent stall after tool result" experience reported in #29881. Happy to share methodology details if useful.