fix: gracefully terminate none-runtime process group on cancel

[zpzjzj]

Summary

The none runtime already starts commands in their own process group and kills the whole group on cancellation, but it did so with an immediate SIGKILL. Children never got a chance to run trap handlers, release locks, or clean up — the exact failure mode the issue describes, where a helper holding a lock left stale state that stalled a later command.

This adds a graceful escalation path:

• On cancel/timeout, the process group is signaled with SIGTERM first, giving children a chance to clean up.
• If the group is still alive after a short grace (noneExecKillGrace = 1s), it escalates to SIGKILL.
• The grace fits inside the existing 2s WaitDelay, so a timed-out Exec still returns within its deadline and preserves the context.DeadlineExceeded / exit-code -1 contract.
• Whole-group semantics (negative PID) and the single-process fallback are kept. Escalation runs out of band (goroutine) so cmd.Cancel returns immediately and os/exec can start its WaitDelay timer; a done channel closed once Wait returns stops the escalation timer before the PID can be recycled.
• No-op on non-Unix platforms (none_exec_other.go, guarded by the same build tags).

Tests

• TestNoneRuntime_ExecTerminatesGracefullyThenEscalates — a SIGTERM trap writes a marker before exit, proving the graceful path runs cleanup rather than an immediate SIGKILL (verified: fails under immediate-SIGKILL, passes with SIGTERM-first).
• TestNoneRuntime_ExecStaleLockDoesNotHangNextCommand — the issue's lock-file regression: a first command times out while a background child records its PID as a lock; after the timeout the child's group is gone, and a second command sees a dead PID (kill -0) and does not hang.
• Existing TestNoneRuntime_ExecKillsDescendantsOnTimeout and the deadline/cancel contract tests still pass.

go build ./..., go vet ./..., gofmt -l clean, and go test -race ./... green.

Fixes #120

🤖 Generated with Claude Code