Previously the editor and palette listened to Gtk.Settings
notify::gtk-theme-name (and notify::gtk-application-prefer-dark-theme)
to re-render their themed icons on theme switch. Two problems:
1. The initial icon load happened during widget construction, before
the buttons were attached to the toolbar — so the style context
resolved to a default (often white) foreground rather than the
actual theme text color. Icons showed up white until the first
theme-change event.
2. Settings notify fires *before* GTK's CSS engine re-resolves styles
for the new theme. Reading the style context's foreground from
that handler returned the previous theme's color, so toggling
light <-> dark left both states settling on the same shade.
Move both responsibilities into a new attach_themed_icon helper in
_icons.py: it does the initial load, connects to the *button's own*
style-updated signal, and rebuilds the icon on each emission. That
signal fires *after* CSS resolution (both on first realize and on
runtime theme switches), so the foreground we read is always the
current one.
A per-button color-key guard skips the rebuild when the resolved
foreground hasn't changed, so unrelated style-updated emissions
(hover, focus, active) don't trigger needless re-renders.
The handler is connected to the button itself, so GTK cleans it up
when the button is destroyed; both editor.py and palette.py drop
their bespoke Gtk.Settings handler bookkeeping.
dfa1cb7ca5