Worker pool priority inversion: chained background slices starve queued foreground requests

Symptom in a worker-pool reader (coordinator + N workers): a UI value read that takes ~20 ms took 20+ s. A per-task debug log (worker, op, wait->done, worker ms, queue depth) showed the cause: one signal's background load was split into ~45 slices of ~0.6 s, and each finished slice immediately scheduled the next one onto the worker ahead of the foreground requests already queued there (every log line showed queue 2 for ~25 s). Making foreground preempt the currently running slice is not enough; the scheduler must also check the foreground queue before starting each next background slice (or run background work on a dedicated worker). Debugging tip: log queue depth on every task completion. A constant non-zero queue during a run of background tasks is the signature of this inversion. Also, when you capture a child's stderr through a wrapper, exec cmd 2> >(tee -a file >&2) keeps the parent's stderr pipe working while saving a copy.