fix(graphics): repair chafa rendering and mpv kitty streaming

[sanohiro]

Summary

Four graphics-protocol bugs found while debugging issue #7 (mplayer fbdev2 playback) by exercising chafa -f sixel, chafa -f kitty, and mpv --vo=kitty on bcon.

• Kitty graphics: per-chunk base64 decode — chafa emits each chunk as a self-contained base64 unit with its own = padding. bcon was concatenating raw base64 across chunks and skipping = during decode, which leaked 2 leftover bits per chunk into the next, producing 600 extra bytes for a 640×480 RGBA image (2400 chunks × 2 bits). Now each chunk is decoded on arrival. Regression test added.
• Kitty graphics: gate responses on client-provided id — the protocol says terminals must not emit responses unless the client set i= or I=. chafa sets neither, so bcon's OK reply was leaking into the shell input as visible text. Introduced Terminal::maybe_send_kitty_response to collapse seven nearly-identical call sites into one gated helper.
• Grid: keep the cursor out of placed image area — place_image advanced the cursor onto the last row occupied by the image (both the scroll and non-scroll paths clamped to rows - 1). The very next put_char then called remove_images_at_cell, discarding the placement we had just created — observed as the second chafa -f sixel run rendering nothing. Unified the branch so the cursor always lands one row past the image, scrolling additionally if needed.
• Grid: dedupe fully-covered overlay placements — mpv --vo=kitty streams identically sized overlay frames (a=T,C=1) at the same cell without ever issuing a delete. bcon accumulated one placement and one ~3MB image per frame, stalling within ~4 seconds because the PTY read loop couldn't drain. place_image now returns the ids of any overlay placements fully covered by the new one at the same z-index, and the Kitty handler drops those ids from the image registry so GPU textures and RGBA buffers are reclaimed every frame.

Also marks sixel-decoded images with dirty_image_ids.push(img_id) so the renderer actually uploads the new texture — previously the sixel decode completed but no GPU upload ever ran, so the placement rendered as a solid black rectangle.

Test plan

• cargo test --release terminal::kitty — new chunked-base64 regression test passes
• chafa -f kitty test.png displays the image with no OK reply leaking into the shell
• chafa -f sixel test.png displays the image; running it a second time still displays
• mpv --no-audio --vo=kitty test.mp4 plays to completion without stalling (throughput is still heavy at full resolution; lower with --vf=scale=480:-2,fps=15 for smoother playback)
• mpv --no-audio --vo=sixel test.mp4 — still broken (DCS parser leaks sixel bytes as printable text mid-stream). Static sixel and Kitty graphics video are unaffected. Tracked as follow-up.

Known follow-ups (not in this PR)

• sixel streaming from mpv --vo=sixel breaks the DCS parser mid-playback
• sixel palette index 255 collides with the decoder's "unpainted" sentinel — image pixels of color 255 render as transparent
• Kitty graphics throughput optimization (SIMD rgb_to_rgba, faster base64, shared-memory t=s path) to make full-resolution video smoother