zoom.sh: killall -10 majestic sends SIGUSR1, which parks a thread instead of reloading config

[widgetii]

general/package/sigmastar-osdrv-infinity6e/files/script/zoom.sh sets a crop and then
signals majestic, in nine places (:146,149,152,159,162,165,172,175,178):

cli -s .video0.crop 0x0x1920x1080 && killall -10 majestic

Signal 10 is SIGUSR1. majestic's reload signal is SIGHUP.

What signal 10 actually does

src/levent.c registers handlers for SIGINT, SIGQUIT, SIGTERM and SIGHUP — and
nothing else. SIGUSR1 is claimed process-wide by the bundled thread pool
(src/thirdparty/thpool.c:318), whose handler is:

static void thread_hold(int sig_id) {
    threads_on_hold = 1;
    while (threads_on_hold) { sleep(1); }
}

thpool_resume() is the only thing that clears threads_on_hold, and nothing in majestic
ever calls it. So whichever thread receives the signal parks in that loop for the life of
the process.

The practical effect is that zoom.sh 31 writes the crop into /etc/majestic.yaml, does
not apply it — a reload was never requested — and leaves a majestic thread suspended.

Scope

zoom.sh ships only on sigmastar-osdrv-infinity6e, is installed into /usr/bin, and is
user-invoked (zoom.sh 31). Nothing in the tree calls it, so this does not fire on its own.

Not reproduced on hardware — I do not have a SigmaStar infinity6e camera. The signal
number, the handler and the absent thpool_resume() call are all read from the source; what
has not been confirmed is which thread receives it and what the user-visible symptom is.
Worth a check by someone with the board before deciding how far the effect reaches.

Fix

Delete the nine killall -10 majestic calls rather than correct them to killall -1.
cli -s now asks majestic to reload after a successful write, so the crop applies on its
own, and an explicit signal would only ask for a second reload inside the 3s window.

Note also that zoom.sh reads with yaml-cli -g directly rather than cli -g, so it
bypasses the wrapper; that is fine for a read, just inconsistent.