fix(coding/execution): prefer the sink error over the operation deadline

[rsbin1178]

The runner took whichever of {process exit, output trigger, context done} arrived
first and kept only that error, so a caller whose sink failed could be told
"context deadline exceeded" instead: the fixture's one-second operation deadline can
expire before the dispatcher goroutine reports the failure, which is what the macOS
sandbox runner hit.

The dispatcher now records the sink's failure beside reporting it on the trigger, and
the run prefers that record: the sink error leads the returned error and any context
error that also happened is joined behind it, so nothing is dropped. The error
classification still sees the preferred error and the status stays canceled.

Measured: a test cancels the caller's context while its sink is running and lets the
sink fail afterwards. Without the preference applied it fails three runs out of three
with "Target error should be in err chain", and with it the caller sees both the sink
failure and the cancellation, twenty -race repetitions.

Evidence

The new runner test cancels the caller context while the sink runs and then fails the sink. With the preference line removed it fails three runs out of three ("Target error should be in err chain"); with it, errors.Is finds both the sink failure and context.Canceled, and the status is canceled. A unit test pins the rule itself: a sink failure leads, a context error is joined behind it, and an already-present failure is not duplicated.

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 #37, which must merge first.