[babo989]

Adds a lightweight `_check_for_stop()` that's polled inside the per-image loop and
between folders, so the dashboard's Stop-segmentation button actually halts a running
pipeline.

• drains stale MQTT messages and resets the interrupt flag at the start of `segment_list`
  (a stale click from a previous run can't kill the next one ideally)
• publishes `Interrupted` instead of `Done` when user-stopped
• skips writing `done.txt` so the folder can be retried"

[babo989]

It's working correctly in my test. From the timeline at 16:51:54–55:

16:51:54.085 segmenter/segment received: {"action":"stop"}
16:51:55.017 planktoscope.segmenter:_check_for_stop:602 — Stop requested during active
segmentation
16:51:55.017 10 images done … (current pipeline broke out of the for-loop at line 650)
16:51:55.052 planktoscope.segmenter:segment_path:943 — Pipeline interrupted by user for
/home/pi/data/clean/2026-03-28/Res1_1/Res1_1_A_2, not marking as done
16:51:55.554 segment_list:814 — Res1_1_A_3 starting (next queue item)

Every piece of the fix fired:

• _check_for_stop() polled the MQTT queue mid-pipeline and consumed the stop message
• The per-image loop broke out
• segment_path saw _interrupt_requested == True and skipped writing done.txt
• The Queue Processor saw Interrupted + seg_queue_user_stop, marked it as user-stopped, and
  advanced to the next acquisition (Res1_1_A_3) — which is exactly the "skip the current
  segmentation" semantic you wanted.

The button does what its label says now. No done.txt was written for the stopped folder, so
it can be retried later.