fix(preview): stop leaking vspipe/ffmpeg when seeking or cancelling

[StuartCameronCode]

Seeking previews and cancelling jobs leave vspipe and ffmpeg running. Three
separate causes, all resting on the same accident.

Nothing ever killed those children deliberately. They tended to die because
their pipes closed with the worker and they took EPIPE at the next write. A child
blocked reading a slow source — a NAS share, in the report — writes nothing for
minutes, never notices, and keeps burning CPU. That also explains why this never
reproduced locally: with fast local I/O the cascade wins every time.

1. Preview mode had no cleanup whatsoever

main() returns at the --preview branch before ctrlc is installed, so
SIGTERM killed the worker outright without unwinding — Drop never ran. And
generate_preview holds vspipe/ffmpeg in locals, so
PipelineExecutor::terminate() could not have reached them even if it had run.

2. A seek could lose a preview entirely

PreviewGenerator tracked one _previewProcess, assigned after
await Process.start(...) returned. A seek arriving inside that window cancelled
whatever the field happened to hold, and the next assignment overwrote the
reference to the in-flight worker — untracked, never killed. Scrubbing cancels a
preview on every movement, so they accumulate. This is the reported symptom.

3. Cancel signalled the pid alone

Even a clean shutdown depended on the worker getting far enough to kill its own
children.

Fix

The worker makes itself a process-group leader (setpgid), so the app can
tear down the whole tree with one signal to -pid. ProcessTree does that, with
a fallback to pid-only signalling where groups are unavailable — which is exactly
today's behaviour, so this is never worse.

PreviewGenerator tracks every live preview in a set, registered at spawn, so
nothing can be lost in that window. Cancellation signals immediately and reaps in
the background — a seek must not wait out a shutdown grace, or scrubbing feels
broken. dispose() uses the waiting variant, since strays outliving the app are
worse than a pause.

Verified, not assumed

• the worker really does become a group leader (pgrp 3362 → 3382)
• Dart really does forward a negative pid to kill(2) (killPid(-pid) → true)
• the group signal kills a child that was SIGSTOPped first, so the result
  cannot be credited to the EPIPE cascade

Two tests: a process-group invariant test that stops the children before
signalling, and a rapid-seek test firing ten overlapping previews. Both would
pass vacuously without the SIGSTOP and the burst respectively — which is why they
are written that way.