perf(images): render iTerm2 inline images in one sequence

[paviro]

Problem

Images render slowly in iTerm2. The cause is not protocol selection — the graphics backend already forces ProtocolType::Iterm2 in iTerm2. It's the encoding: images were built with ratatui-image's SlicedProtocol, which for the iTerm2 protocol slices the image into one PNG + one OSC 1337 inline-image sequence per terminal row. A ~50-row fullscreen image emits dozens of PNG encodes and inline-image sequences for the terminal to decode and place.

Slicing only matters when an image scrolls partially in and out of view. The fullscreen image viewer never scrolls an image, so the slicing was pure overhead — paid only for SignedPosition-based centering, which the plain Image widget does just as well.

Change

Switch the graphics path from SlicedProtocol/SlicedImage to the non-sliced Protocol/Image widget across graphics.rs, worker.rs, and mod.rs:

• iTerm2 now emits a single whole-image OSC 1337 sequence.
• Kitty and Sixel keep their single transmission / single DCS.
• Centering is done by rendering Image::new(&proto) into a centered sub-Rect.

The color-managed decode pipeline (EXIF, ICC→sRGB, viewport downscale cap), background worker builds, and cache are unchanged.

Verification

• cargo build clean, no warnings.
• cargo test --lib tui::image passes (7 tests).
• Manual check in iTerm2: open an entry's image in the fullscreen viewer — appears near-instantly; ←/→ nav and resize paint promptly, centered/letterboxed. Optionally capture output under a pty and confirm exactly one ESC ]1337;File=inline=1 per image instead of one per row.