fix(downloads): GIF review round 3 — every length readout, live regions in place

A refused GIF's length reads rounded up everywhere the editor shows it (the segment and the kept summary of one), and the GIF notes and estimates sit in live regions that are there before GIF is picked, so a note already true then is said. Tests hold the clip panel's readout and which segment a note names; DESIGN.md claims only what the contract test holds.

docs/DESIGN.md

@@ -651,8 +651,9 @@ of a full-width panel and nothing on the right.
   (the long side: 320 / 480 / 640 px), the expected size ("about 4–10 MB"; one number when both ends read the
   same), a note over 15 MB (a chat's link preview will not move) or 30 MB (it may be refused), and over 30 s
   the reason, with Make GIF unavailable. A refused length is shown rounded up, never as one the cap allows. The
-  cap is judged in whole milliseconds between the ends as sent, the server's own rule (`lib/gif`, held to
-  `downloads/gif.py` by `gif.contract.test.ts`). The editor has its own Format row (a video only): with GIF
+  cap is judged in whole milliseconds between the ends as sent, the server's own rule (the limits in `lib/gif`
+  are held to `downloads/gif.py` by `gif.contract.test.ts`; the rule itself is written on each side and
+  tested there against the same boundary cases). The editor has its own Format row (a video only): with GIF
   each kept segment is a GIF of its own, Join is unavailable with its reason in a tooltip, the precise / fast
   choice gives way to one line (a GIF is always re-encoded), and the notes name each segment over a limit,
   in one live region. A shared GIF's page shows the picture itself (no player), its name, kind and size, its