fix(lock): release profile lock early on SIGINT/SIGTERM

[MrBeldum]

Summary

Fixes #548 — profile lockfiles can remain after SIGINT/SIGTERM.

defer runLock.Release() only runs when run() returns. After a termination signal the process may still spend time in run-after-fail / finally hooks or waiting on a child; systemd (and similar) often follows up with SIGKILL (TimeoutStopSec). If that happens before run() returns, the lockfile is left behind.

This is distinct from the closed attempt in #627 (which assumed os.Exit skipped defers — it does not, because that defer is registered first in main). The fix here is early release on signal, not fixing defer ordering.

Changes

• While holding the profile lock, watch SIGINT/SIGTERM/SIGABRT on a dedicated signal.Notify channel (does not compete with the shared sigChan used to forward signals to child processes).
• Release the lock as soon as the signal arrives; still release on the normal return path.
• Make Lock.Release() idempotent (sync.Once) so the signal and normal-exit paths are safe under -race.
• Tests: lock disappears during run() after SIGTERM; normal return still releases; Release() is idempotent.

Test plan

• go test -race -count=1 . -run TestLock
• go test -race -count=1 ./lock/ -run 'TestRelease|TestLock'
• CI green
• Manual: start a long profile with a lockfile, send SIGTERM, confirm lockfile is gone even if cleanup is still running

Fixes #548