Wide-cell repaint corrupts rows under tmux

[ostrich]

Description

Summary

Ultraviolet 68fa937c71be severely corrupts a fullscreen Bubble Tea display containing emoji under tmux. Rows are duplicated, displaced, partially overwritten, or replaced with blank lines.

Reverting only Ultraviolet to 8b693049ce2a restores stable rendering.

Environment

• Bubble Tea v2.0.9
• ANSI v0.11.8
• Broken Ultraviolet: 68fa937c71be
• Working Ultraviolet: 8b693049ce2a
• Linux ARM64, tmux 3.7c
• Konsole 26.04.3 over SSH
• en_US.UTF-8
• Fullscreen alternate-screen application

The corruption is present in tmux capture-pane, so it is not just stale pixels in Konsole. No terminal graphics were active.

Behavior

The application renders a chat buffer beside a fixed-width sidebar. It uses styled trailing padding but deliberately leaves the final terminal column unused. Its wrapping and padding use the same negotiated width method as Bubble Tea: ansi.WcWidth by default and ansi.GraphemeWidth only after a successful DEC mode 2027 report.

The initial isolated symptom involved U+1FAC6 FINGERPRINT (🫆) shifting a sidebar border. After upgrading Ultraviolet, periodic screen updates began duplicating rows that were already on screen. For example, the same three messages could appear twice in succession:

(08:02:21) alice: ordinary message             | sidebar
(08:03:04) bob: 👽                             | sidebar
(08:03:19) carol: 🥂                           | sidebar
----- the same rows are incorrectly drawn again -----
(08:02:21) alice: ordinary message             | sidebar
(08:03:04) bob: 👽                             | sidebar
(08:03:19) carol: 🥂                           | sidebar

As repainting continued, additional copies accumulated and some later rows were drawn at the wrong vertical position or lost their leading characters.

Only the Ultraviolet revision changed. Application tests, vet, and race tests pass with both revisions.

Possible relation to #163

This may be related to #163, which describes lineHasDrift repainting unchanged rows that contain wide characters. That issue was withdrawn because it was filed from the wrong account, and I couldn't find the replacement the author said they planned to open.

In my case, the result isn't just unnecessary output. Once the terminal and renderer disagree about a character's width, the cursor tracking appears to get out of sync and later updates are drawn on the wrong rows.

Related issue #160 discusses trailing padding and pending-wrap behavior, which may also be relevant.

Expected

A width disagreement may misalign one glyph, but it should not corrupt other rows or accumulate damage across frames. Unchanged wide-cell rows should not be repainted unnecessarily.

Version

No response

Environment

No response