[vyncint]

While a chunked kitty upload (m=1) was in progress, three things that cannot continue it completed it instead:

• A sixel was built on top of it: one payload, described as a sixel but carrying the kitty s=, c=/r=, t=, i=, o=, whose data was the kitty chunk and the sixel run together — it decoded to a transparent 4x6 instead of the red it painted.
• A delete (a=d) was taken as the upload's last chunk: kitty() counted an image, deletes() missed the teardown. The protocol: "the partial upload must be aborted".
• Any APC, not only G, was taken as a chunk (and, with no m=1, as the last one); after RIS the next transmission completed the upload.

Fix. Only a G APC continues an upload. A delete aborts it and is then counted as a delete; a sixel or RIS abandons it. DECSTR keeps it, as kitty's soft reset does (it skips the grman_clear the hard reset runs — kitty screen.c / graphics.c, read at 2a70f21). An abandoned upload is no image; its chunks still count in bytes(), which counts traffic, not pictures, so bytes() is unchanged for every stream.

Tests (unit, emu/seq.rs, the issue's exact sequences): sixel mid-upload (plus its decode under decode), delete mid-upload, RIS vs DECSTR, a non-G APC. All five failed on main showing the issue's symptoms; restoring each piece of the old behaviour on its own turns exactly its test red. DESIGN.md's counter paragraph also said continuations "carry no control block at all" — they carry m=; corrected.

Not changed (outside the issue, noted for later): a=p/a=c or a new non-direct t= sent mid-upload, which kitty handles separately and the protocol forbids.

Closes #587