fix(waiter): guard signal.signal() calls for non-main threads

[eason-hk-barcelona]

Summary

• Guard signal.signal() calls in TaskWaiter.wait() with a main-thread check to prevent ValueError when the waiter runs inside a worker thread.

Problem

TaskWaiter.wait() unconditionally calls signal.signal(signal.SIGINT, ...) to install a graceful-shutdown handler. Python requires that signal.signal() is only called from the main thread of the main interpreter — calling it elsewhere raises:

ValueError: signal only works in main thread of the main interpreter

This was not an issue when tasks ran serially, but breaks under parallel execution (e.g. MASP-Bench with RUN_ALL_WORKERS=4), where the call chain becomes:

bash &  →  python -m masp_bench run  →  asyncio event loop
    →  loop.run_in_executor(None, waiter.wait)   # worker thread, not main thread
        →  signal.signal(...)                     # 💥 ValueError

Fix

Added a threading.current_thread() is threading.main_thread() guard around signal handler installation and restoration. When wait() runs in a non-main thread, signal handling is simply skipped.

Trade-off: Tasks running in worker threads cannot be gracefully interrupted via Ctrl+C — they must rely on timeout or explicit termination. This is an acceptable degradation since the core polling and task-completion logic is unaffected.

Changes

• clawteam/team/waiter.py: Added import threading, wrapped signal.signal() / signal.getsignal() calls with a main-thread guard.

[eason-hk-barcelona]

@tjb-tech