[Bug] WezTerm: inline images degrade to a one-row sliver (vendored pi-tui kitty path lacks scroll awareness)

What version of Kimi Code is running?

0.31.1 (also reproduced on current main — the code path is unchanged)

Which open platform/subscription were you using?

Kimi subscription (weekly quota)

Which model were you using?

kimi-code/k3-256k (rendering issue, model-independent)

What platform is your computer?

Linux 6.6.114.1-microsoft-standard-WSL2 x86_64 (WezTerm terminal, also reproducible on native Linux/macOS WezTerm)

What issue are you seeing?

On WezTerm, an image shown inline in the transcript (e.g. a pasted image thumbnail) renders as a one-row sliver — only the top sliver of the picture is visible above a blank area where the rest of the image should be. After scrolling, even the sliver can disappear.

What steps can reproduce the bug?

1. Run kimi in WezTerm (no tmux).
2. Paste an image into the prompt, or have a session that contains an image attachment rendered in the transcript.
3. The thumbnail renders as a thin strip instead of the full image.

detectCapabilities() in packages/pi-tui/src/terminal-image.ts maps WezTerm to the kitty graphics protocol, so the Image component emits a kitty placement.

What is the expected behavior?

The full image renders inline and survives transcript scrolling/redraws, as it does in iTerm2-protocol terminals.

Additional information

Root cause analysis:

• The vendored packages/pi-tui (0.80.8) encodes kitty images as a one-shot, cell-anchored placement: encodeKitty emits the image once at the cursor, and nothing re-emits or re-crops it afterwards.
• WezTerm's kitty implementation drops image content wherever text rows are (re)written over the placement (wezterm#986). A scrolling/redrawing transcript constantly rewrites rows, which punches holes in the image until only a sliver remains.
• This is fixed in current upstream @earendil-works/pi-tui (0.83.0): the renderer is scroll-aware for kitty graphics — registerKittyImageMetadata + cropKittyImageLine (used from layout.ts) re-emit cropped placements as rows scroll. pi 0.83.0 renders images correctly on WezTerm with kitty.
• WezTerm also supports the iTerm2 inline-image protocol, whose images are attached to the emitting line and scroll with the buffer — immune to this class of problem.

Possible fixes, smallest to largest:

1. Prefer the iTerm2 protocol on WezTerm in detectCapabilities() (one branch + a test). Pragmatic; matches what several other tools do. I have this working as a local patch and can open a PR.
2. Backport the scroll-aware kitty machinery (cropKittyImageLine etc.) into the vendored renderer. Invasive: the vendored renderer predates upstream's layout.ts pipeline that the cropping hooks into.
3. Re-vendor current upstream pi-tui (0.83.0). The proper long-term fix, but upstream has since restructured (layout.ts, tui-main-screen.ts, new components), so it's a larger migration.

Upstream reference: I initially filed this against earendil-works/pi (earendil-works/pi#7481, PR earendil-works/pi#7482) and closed both after confirming current upstream is unaffected — the bug only exists in the older vendored snapshot here.

Start in packages/pi-tui/src/terminal-image.ts at detectCapabilities(), then inspect the vendored kitty-image path and the issue's reproduction in WezTerm. Compare the protocol options described in the report and verify that the chosen fix makes the full image survive transcript scrolling and redraws.