feat(coding-agent): diagnose when a child holds stdio open past exit

[Mearman]

Follow-up to #5753. When reviewing that PR you noted it doesn't change that we can end up waiting for the actual bash timeout to kick in. That's true and it's the right behaviour — if a detached descendant keeps writing after the shell exits, re-arming the grace is what stops us truncating the tail. But it's invisible: the command reads as a slow hang with nothing to say the process itself had already exited and a held-open pipe is what kept us reading.

This adds an opt-in PI_STDIO_DEBUG=1 that logs, when the wait resolves, how long a process held stdio open past exit, how much it read in that window, and which path released us (clean eof / idle grace / close). Gated exactly like PI_TIMING, off by default, zero overhead when unset, and it only fires when output actually arrived after exit — i.e. the case that can stretch to the timeout, not every backgrounded handle.

Example line:

[stdio] pid 41234 exited but held stdio open for 4920ms past exit (98 chunk(s), 31610B read after exit; resolved via close)

npm run check and ./test.sh both pass. Two tests in test/child-process-stdio-debug.test.ts: one that the line is emitted with the flag on, one that it stays silent with it off.

[mitsuhiko]

I don't want to add something like this for the moment. Let's cross that line when it comes up :)