feat: chain track 5 frames so a moving object is re-seeded (REQ-189)

trackForward sent the identical box to all five target frames. On batch 19
(extracted at 0.5 fps - one frame every 2 s) a truck entering the frame
outruns a static seed, so the action either missed it or grabbed the wrong
part.

- geometry handling lifted to module-level shapeBox(), reused for the drawn
  shape and for each assist result
- first frame still uses the drawn box exactly; frames 2-5 are seeded with
  the previous run's shape grown x1.5 about its centre (SEED_GROWTH)
- a frame SAM3 refuses keeps the last good seed for the next attempt
- REQ-189 rewritten to the chaining contract, including the accepted cost:
  a bad read can carry forward; this is not tracking, no motion model

docs/ui-spec.md

@@ -995,7 +995,13 @@ previous geometry** and shows the error. Same optimistic-with-rollback pattern f
   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 (REQ-189).
+  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).
 
 **Quick reclass bar** appears whenever a shape is selected: one button per class
 (`[n] name`, class-coloured) plus *Delete [Del]*.