tests/kaggle/test_launch_cleanup.py drives a real subprocess, signals it, and then discards its output. When a signal test fails, the message says only what the exit status was.

The discarded output contains the one line that decides where to look. _install_release_handlers logs received signal N; deleting kernels before exiting the moment its handler runs, so its presence separates two different faults:

• the signal never reached the handler, or
• the handler ran and the process still exited 0.

Why now

CI produced the second symptom on a runner whose checkout carries the handler fix from #9072 (verified against the branch, not assumed). It does not reproduce locally at four cores under -n 4, across repeated runs. The only evidence that could distinguish those two cases was being thrown away.

The change

Both failure paths report the tail:

• the assertions on exit status and on deletion include it;
• the wait is routed through a helper, so a launcher that never dies names the handler too rather than raising a bare TimeoutExpired. Killing first is what lets the pipe reach EOF so the tail can be read at all.

The read happens only after the process has exited, so it cannot block.

Verification

Against two mutations of the handler, one exiting 0 and one returning without dying, each failure now carries:

Launcher said: [launch] received signal 15; deleting kernels before exiting

No behaviour changes and no bound moves. This is diagnostics only.