watch: handle SIGHUP in watcher interrupt path

[SergioChan]

Summary

• include syscall.SIGHUP in the watcher interrupt signal handler
• watcher mode now exits/restarts on SIGHUP just like SIGINT/SIGTERM

Testing

• Unable to run go test ./... locally in this environment because the repository requests Go 1.25 toolchain and automatic toolchain download is unavailable here (toolchain not available).
• Change is a single signal list update in closeOnInterrupt, with no behavioral impact outside watch-mode signal handling.

Related

• Fixes Watcher interrupt on SIGHUP #2642

[trulede]

What would happen if both SIGTERM and SIGHUP are received in quick succession? Is it going to restart the watcher, or exit Task.

Possibly call signal.Stop(ch) before w.Close(),

[SergioChan]

Good point — I pushed a follow-up commit (21afafb8) to make the signal path explicit and avoid double-delivery races.

Change

• Added signal.Stop(ch) before w.Close() in closeOnInterrupt.

Effect

• Once the first interrupt signal is received, we stop further notifications on that channel before closing the watcher and exiting.
• This avoids handling a rapid second signal on the same channel while shutdown is already in progress.

Behavior remains the same (watch process exits on SIGINT/SIGTERM/SIGHUP), but the shutdown path is now safer/cleaner.