[jsc] don't override JSC's thread suspend signal on FreeBSD - #44596

What does this PR do?

Bun protects the signal JSC uses to suspend/resume threads from being overridden by a JS listener (process.on(...)) only under #if OS(LINUX):

#if OS(LINUX)
    // SIGKILL and SIGSTOP cannot be handled, and JSC needs its own signal handler to
    // suspend and resume the JS thread which we must not override.
    if (signalNumber != SIGKILL && signalNumber != SIGSTOP && signalNumber != g_wtfConfig.sigThreadSuspendResume) {
#elif OS(DARWIN) || OS(FREEBSD)
    // these signals cannot be handled
    if (signalNumber != SIGKILL && signalNumber != SIGSTOP) {   // <-- no suspend-signal guard

JSC picks that signal in wtf/posix/ThreadingPOSIX.cpp: SIGPWR on Linux, SIGUSR1 everywhere else (including FreeBSD). So on FreeBSD a process.on('SIGUSR1', ...) listener makes Bun install its own SIGUSR1 handler and clobber JSC's. The GC/VMTraps suspend signal is then delivered to Bun's handler, globalSemaphoreForSuspendResume is never posted, and anything that suspends a thread never resumes — tearing down a VM (e.g. a Web Worker, WebWorker__teardownJSCVM → destroyVM) deadlocks.

This is easy to hit: any JS dependency that handles SIGUSR1, or just process.on('SIGUSR1', () => {}), breaks GC suspension for the life of the process.

How did you verify your code works?

On FreeBSD/aarch64 (a compiled bun --compile app that registers a SIGUSR1 listener), before the change the process deadlocked on exit 5/5. With this change the same deterministic test is exit=OK 15/15, and the JS turns it exercises still pass.

Instrumentation used to confirm the mechanism:

• A write(2) log in Thread::signalHandlerSuspendResume (to a dedicated file fd) showed the handler never executes, while the suspender's side (Thread::suspend) does run.
• ktrace -t s showed PSIG SIGUSR1 caught ... code=SI_LWP delivered to the owner thread but to a non-JSC handler; the thread's mask is clear and its sigfastblock word is 0.
• Live stacks on the hang: VMTraps::SignalSender::work() → Thread::suspend() → sem_wait, with a GC helper blocked in MachineThreads::tryCopyOtherThreadStacks → the process-global suspend lock the sender holds.

oven-sh/WebKit#693 (the signalHandlerSuspendResume request/generation rework) does not fix this, which is consistent: the problem is that JSC's handler is not installed at all.

Risk

Low. It only makes FreeBSD behave like Linux for sigThreadSuspendResume: Bun will refuse to install a JS listener for it, the same way it already does on Linux. macOS is unaffected (it uses Mach thread suspension, not signals), so the SIGUSR1 guard is #if OS(FREEBSD) only.