fix: unchain track 5 frames so one bad read cannot poison the rest

The chained attempt (1530bbc) fed each run's result into the next frame's
seed, so a wrong read on one frame carried into the ones after it. Runs are
independent again: every frame is seeded from the drawn shape, frames 2-5
with it grown x1.5 about its centre for motion tolerance. REQ-189, ui-spec
and tasks.md updated to the independent contract.

docs/ui-spec.md

@@ -989,19 +989,21 @@ previous geometry** and shows the error. Same optimistic-with-rollback pattern f
 - *Copy Prev* copies every annotation from frame `n-1` onto this frame (one POST per shape);
   disabled at index 0 or when the previous frame is empty.
 - *Track 5 Frames* takes the selected shape's bounding box and runs SAM3 assist on the next 5
-  frames with it. Works for both geometry types: a bbox shape supplies its own box, a polygon
+  frames with it — the first with that box exactly, the rest with it grown (see below). Works
+  for both geometry types: a bbox shape supplies its own box, a polygon
   is reduced to its bounding box. Nothing selected, an unusable shape, or the last frame
   says so in the error slot instead of silently doing nothing; a frame SAM3 refuses (nothing
   inside the box) does not stop the rest — the banner then **starts** with `Tracked N of M`
   (M = frames actually ahead, ≤ 5) followed by the per-frame failures. A second press while
   a run is in flight is ignored. Shapes are written `source=manual`, exactly as a hand-drawn
   one.
-  Runs are **chained**: the first frame uses the drawn box exactly, and every later frame is
-  seeded with the previous run's resulting shape, grown ×1.5 about its centre so a moving
-  object still fits. A refused frame keeps the last good seed for the next attempt. Chaining
-  is not tracking — there is no motion model — so a wrong read can carry forward; only denser
-  frame extraction (higher fps) or real video propagation fixes a fast-moving object
-  (REQ-189).
+  Runs are **independent**: every frame is seeded from the drawn shape, never from another
+  run's result, so a wrong read on one frame cannot poison the ones after it. The first frame
+  uses the drawn box exactly; frames 2–5 use it grown ×1.5 about its centre so a moving object
+  still fits the seed window. A refused frame does not stop the rest. Because nothing carries
+  between frames there is no size/position readjustment — a fast-moving object can still
+  outrun the seed; only denser frame extraction (higher fps) or real video propagation fixes
+  that (REQ-189).
 
 **Quick reclass bar** appears whenever a shape is selected: one button per class
 (`[n] name`, class-coloured) plus *Delete [Del]*.