[BUG] "theme" in settings.json is not applied to a running session (atomic and in-place writes tested)

Summary

theme written to settings.json is not applied to an already-running session. A session started before the write keeps its previous palette for the rest of its life. The docs state the opposite — https://code.claude.com/docs/en/settings#when-edits-take-effect says Claude Code watches settings files and applies most edits without a restart, and lists only model, effortLevel and modelSettings as startup-only.

This is the non-auto half of the problem described in #92389: there, "theme": "auto" never re-samples because re-sampling is gated on DECSET 2031. Here the theme is a fixed value that should need no notification at all, and it still doesn't land.

Environment

• claude 2.1.220 (installed binary, stable)
• Linux, Fedora, GNOME/Ptyxis (VTE), inside and outside a terminal multiplexer (both tested)
• Theme value: a custom theme (custom:<slug>, ~/.claude/themes/<slug>.json) in the recorded run; dark/light builtins behave the same

Reproduction

1. Start a session and leave it open.
2. Write the new value into ~/.claude/settings.json, via both write styles:

• atomic: tempfile + os.replace (replaces the inode)
• in-place: open(path, "r+") → write() → truncate() (same inode, so any fs.watch on the path stays valid)

1. Observe the session: the palette does not change. Ten minutes after the write, a message typed in that session is still rendered with the previous palette.

How the effect was measured (no eyeballing)

Claude Code paints the user-message block with a background colour taken from the effective theme. Reading the pane's raw output (--format ansi equivalent) shows 48;2;240;240;240 (light palette) vs 48;2;55;55;55 (dark palette). After writing the dark theme, a newly typed message still came back as 48;2;240;240;240 with black text — the session was still on the light palette.

Note the method: this is a fresh render, not stale scrollback, which is what makes it conclusive (existing on-screen content keeps its original escape codes and would have been ambiguous).

Impact

Any long-lived session is stranded on the palette it started with. On a workstation that switches appearance twice a day, every open session must be corrected by typing /config theme=… in it, one by one — there is no scriptable path (no CLI flag, no socket, no hook can set it; theme is not in the config-file reload set either).

Ask

Make theme behave as documented: re-read and apply it to running sessions when the settings file changes. If that is deliberately not supported, the docs section above should list theme among the startup-only keys.