[BUG] theme: "auto": message blocks keep the colors of the theme they were drawn under; a live appearance switch never repaints them

### Preflight Checklist

- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code

### What's Wrong?

With `"theme": "auto"`, switching the system appearance while `claude` is running leaves every **already-rendered** user-message block drawn in the *previous* theme's colors. Content rendered after the switch uses the new theme, so the session ends up mixed.

It is not direction-specific:

- start in light → switch to dark: message blocks stay **white** against the now-dark UI
- start in dark → switch to light: they stay **dark** against the now-light UI

Switching the system appearance back makes them look correct again, because the stale color happens to match once more.

`Ctrl+L` and resizing the terminal — a full alt-screen repaint — do **not** fix it. `/theme` → any theme → `/theme` → `auto` does.

Detection itself is fine: the terminal supports DEC mode 2031, and Claude Code re-queries the background on every appearance change. The problem is purely that blocks already on screen are never repainted.

### What Should Happen?

Already-rendered blocks repaint in the newly detected theme, the same way they do when the theme is changed through `/theme`.

### Error Messages/Logs

```
Capturing the pty across an appearance flip, the same block is drawn as:

dark -> ESC[48;2;0;0;0m
light -> ESC[48;2;240;240;240m

with the foreground palette switching too (153;153;153 -> 102;102;102, 44;122;57),
and exactly one OSC 11 query at startup plus one more per appearance flip.

So both palettes resolve correctly; only previously drawn blocks keep the old ones.
```

### Steps to Reproduce

1. Set `"theme": "auto"` in `~/.claude/settings.json`, in a terminal that supports DEC mode 2031 (Ghostty 1.3.2 here).
2. With the system in **light** appearance, start `claude` and send two messages, so two user-message blocks are on screen.
3. Switch the system appearance to **dark**.
4. The assistant text below them switches to the dark theme, but the two message blocks keep their light background.
5. `Ctrl+L` and resizing the terminal do not change them. `/theme` → dark → `/theme` → auto repaints them correctly.

### Claude Model

Opus

### Is this a regression?

I don't know

### Claude Code Version

2.1.275 (Claude Code)

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Other — Ghostty 1.3.2-main

### Additional Information

- Reproduces in a plain Ghostty window with **no multiplexer involved**.
- macOS 27.0 (build 26A428), Apple Silicon. `"tui": "fullscreen"`.
- Related but distinct: #86048 (`auto` resolves to the inverted theme) and #92389 (no resample when mode 2031 is unsupported). Here detection works and resolves correctly; the problem is that blocks already on screen are never repainted.

Reproduce the issue with theme set to "auto" in a DEC mode 2031 terminal, then compare the appearance-change path with the /theme path that repaints correctly. Trace how already-rendered user-message blocks are handled after a system appearance switch; done means existing blocks repaint to the newly detected theme without requiring /theme, Ctrl+L, or resizing.

Written by the indexing model from the issue text.