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/requirements.md

@@ -171,16 +171,19 @@ changes.
 - **REQ-189** — In the review editor, the user can push the **selected shape's** box forward
   with *Track 5 Frames* (`[T]`): the next five frames each get their own REQ-043 box-assist
   run, and the shape is written as `source=manual`. Both geometry types work — a bbox shape
-  supplies its own box, a polygon is reduced to its bounding box. Runs are **chained, not
-  independent**: the first frame gets the drawn box untouched, and after each successful run
-  that run's resulting shape seeds the next frame, grown about its centre by ×1.5 so the
-  object has room to have moved. A frame SAM3 refuses (nothing inside the box) is reported
-  and the run continues from the last good seed. Nothing selected, an unusable shape, or the
-  last frame says so instead of doing nothing. Known cost of chaining: a wrong read on one
-  frame can carry into the ones after it — the result banner reports only what happened. This
-  is one-shot hand-off across the next frames, **not** propagation of drawn exemplars (which
-  stays a non-goal): nothing is tracked frame-to-frame with a motion model, and the runs do
-  not share state between invocations.
+  supplies its own box, a polygon is reduced to its bounding box. Runs are **independent**:
+  every frame is seeded from the drawn shape and never from another run's result, so a wrong
+  read on one frame cannot carry into the ones after it. The first frame uses the drawn box
+  untouched; frames 2–5 use it grown about its centre by ×1.5, giving a moving object room
+  to be inside the seed window. A frame SAM3 refuses (nothing inside the box) is reported and
+  the remaining frames still run. Nothing selected, an unusable shape, or the last frame says
+  so instead of doing nothing. Consequence accepted: without chaining there is no size or
+  position readjustment between frames, so a fast-moving object can still leave the seed
+  window — denser extraction (higher fps) or a video-propagation requirement (not yet
+  written) is the fix. This is
+  one-shot hand-off across the next frames, **not** propagation of drawn exemplars (which
+  stays a non-goal): nothing is tracked frame-to-frame with a motion model, and the runs
+  share no state between invocations.
 - **REQ-044** — All annotations and review statuses are **persistent** — they survive a
   server restart, unlike today's in-memory sessions.
 - **REQ-045** — Review progress is visible (e.g. "120/300 reviewed"), and a batch can only