fix(coding/execution): drain the pipes before reporting the capture

[rsbin1178]

finishIO closed the read ends on three of its four branches before the readers had
necessarily drained, including the one an output trigger takes. Closing them makes a
pending Read come back as os.ErrClosed, so the retained capture and the byte count
described how fast the readers happened to be scheduled rather than what the process
wrote: on CI the head of a twenty-six byte output held one byte where the test
expects five.

The trigger branch now drains the readers first and force-closes only when the drain
grace expires, which is the bound the other branches already relied on. The output
limit stays a truncation rather than a failure, and the process is still stopped by
the trigger in waitForProcess.

Measured: a new test drives finishIO directly with the trigger fired and the readers
still running. It fails against the previous implementation with
"write |1: broken pipe" and passes with this change, twenty -race repetitions each.

Evidence

The new test drives finishIO with the trigger already fired and the readers still running, then writes to the process end after it returns: the previous implementation reports write |1: broken pipe (the read end was cut), and this one writes cleanly. It passes twenty -race repetitions.

The fixture that failed on CI (CaptureBytes = 10, ChunkBytes = 1, a 2ms sink) is the integration guard: it asserts the head holds abcde, the tail vwxyz and TotalBytes is 26 while the queue drops chunks.

TERM=xterm-256color go test ./... (89 packages), go test -race -count=20 ./internal/coding/execution/ and golangci-lint run --new-from-rev=HEAD~ ./... (0 issues) are clean.

Based on #36, which must merge first.