ANSI color code bleeding when UI elements wrap in terminal

<img width="1194" height="300" alt="Image" src="https://github.com/user-attachments/assets/d577fe29-8a3c-4fd6-8fb9-412d4a3cefbd" />

Bug Description

ANSI color codes bleed between UI elements when terminal wrapping occurs. Specifically, when both the purple "accept edits on" text and yellow native installation warning are displayed, the grey "(shift+tab to cycle)" text turns purple when it wraps to a new line.

Steps to Reproduce

1. Enable automatic edit acceptance mode (shows purple "accept edits on" text)
2. Trigger native installation warning (shows yellow warning message)
3. Resize terminal width to force the grey "(shift+tab to cycle)" text to wrap to a new line
4. Observe that the wrapped grey text becomes purple instead of remaining grey

Expected Behavior

The grey text "(shift+tab to cycle)" should remain grey even when wrapped to a new line due to terminal width constraints.

Actual Behavior

When the grey text wraps below the purple "accept edits on" text, it inherits the purple color. This appears to be ANSI escape sequence bleed - the purple color code from earlier text is not properly reset before the grey text, causing the grey text to inherit the purple color when the terminal naturally wraps the line.

Possible Cause

ANSI color codes are not being properly reset between colored segments. When terminal line wrapping occurs (natural wrapping, not \n), the terminal continues using the previous color if:

• The color wasn't explicitly reset after the purple text (using \x1b[0m)
• The grey text doesn't explicitly set its own color before rendering

Environment

• OS: macOS 24.6.0 (Darwin)
• Terminal: Ghostty 1.2.3 (xterm-ghostty)
• Claude Code Version: 2.0.27
• Issue Location: UI elements displayed directly under user input