Closes the v0.21.2 carve-out: dynamic-paint sites that were left
un-tagged because their paint cycles were assumed to race
`update_high_contrast_borders`. Re-reading the code revealed only
one of three sites is actually a border-paint cycle — the other
two paint backgrounds, with static borders that take the marker
pattern cleanly:
* HUD action buttons (`spawn_action_button`): `paint_action_buttons`
only mutates `BackgroundColor`. Tag the spawn with
`HighContrastBorder::with_default(BORDER_SUBTLE)`.
* Modal buttons (`spawn_modal_button`): `paint_modal_buttons` also
only mutates `BackgroundColor`. Same marker pattern.
* Radial menu rim (`radial_redraw_overlay`): full despawn-respawn
every frame; sprites, not UI nodes; the marker can't apply. Folds
the HC choice into the spawn site instead — under HC the
*focused* rim boosts to `BORDER_SUBTLE_HC` rather than
`BORDER_STRONG`. Naive marker substitution would invert the
visual hierarchy because `BORDER_SUBTLE_HC` (#a0a0a0) is lighter
than `BORDER_STRONG` (#505050); folding the choice in keeps the
focused rim *more* visible under HC, not less.
Decision logic for the rim is extracted to `radial_rim_outline` —
a pure function with a 4-row truth-table test (focused × HC).
After this commit, every UI surface tagged in v0.21.x's
accessibility arc either carries `HighContrastBorder` or has its
HC behaviour folded into its own spawn cycle. No "un-tagged
because race-risk" surfaces remain.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
funman300
c153363626