stylesheet_resolved() is loaded *only* by the per-monitor bind path
(gtk::bind_window* / reload_binds_for_sanitized), which attaches it as a
widget-tree CssProvider carrying one output's palette. It already hex-
inlines every rule body, but it still emitted the leading @define-color
accent/bg/on-* block verbatim.
@define-color in GTK4 is stylesheet-global -- not provider- or subtree-
scoped (confirmed by GTK's CSS maintainers). So every bind and every
per-output reload redefined the display-global @accent/@bg/@on-* to that
monitor's palette, and any CSS parsed afterwards in another window --
apply_shared in every other bread app, apply_app_css, apply_user_css --
resolved its named colours against whichever monitor bound last. That is
exactly the "wrong monitor's accent leaks" failure the hex-inlining was
added to prevent, just displaced out of the bound tree.
Drop every @define-color line from the _resolved output: the rules are
fully self-contained hex, so the block was pure liability there. The
display-global sheet (stylesheet() / render(), loaded at APPLICATION
priority) keeps its block -- that is the one provider meant to own those
names. Tightens the existing regression test to assert the block is now
actually absent, and adds one guarding the display-global sheet still
carries it.
da23bf50ca