ARTEMIS-6090 Override the topology node colour for dark mode

[opensource-joe]

I went looking for a fix for this and came back with a result that is more useful than a patch, so I am posting the measurements rather than a speculative change.

Against main at dcb6580. All ratios computed from the WCAG 2.1 relative luminance formula, against the three PatternFly v5 dark surfaces.

The tokens the console overrides for dark mode all pass

app/public/css/artemis.css defines an Artemis dark palette and maps the PatternFly tokens onto it inside .pf-v5-theme-dark. Those values are comfortable:

Token	Value	on #151515	on #1b1d21	on #212427
primary-color-dark--100	#d9c8e6	11.61:1	10.73:1	9.92:1
primary-color-dark--200	#daabfd	9.76:1	9.02:1	8.34:1
primary-color-dark--300	#b578ea	5.95:1	5.50:1	5.08:1
primary-color-dark--400	#9989a7	5.64:1	5.22:1	4.82:1

Worst case 4.82:1, so everything routed through the dark palette clears AA.

That matters for this issue specifically, because in dark mode links resolve to --pf-v5-global--link--Color: var(--artemis-global--primary-color-dark--200) and sort arrows resolve to .pf-v5-theme-dark svg.pf-v5-svg { fill: var(--artemis-global--primary-color-dark--200) }. Both are #daabfd, which measures 8.34:1 to 9.76:1.

So the muted purple described for links and sort indicators does not appear to come from the Artemis dark tokens. Either those elements are falling through to PatternFly's own dark defaults rather than the Artemis overrides, or something at runtime differs from what the stylesheet implies. I could not settle which without running the console against a broker, and I would rather say that than guess.

Three tokens are set for light mode and never overridden for dark

Diffing the two blocks in artemis.css, four PatternFly tokens are set in the light block and absent from .pf-v5-theme-dark. One is --pf-v5-c-page__sidebar--Width, a width, so it is fine. The other three are colours and keep their light-mode values on a dark background:

Token	Keeps	Effect in dark mode
--pf-v5-topology__node--Color	#714099	2.15:1 to 2.52:1 against the dark surfaces
--pf-v5-c-button--m-primary--BackgroundColor	#885bad	white text on it is 5.06:1, so readable, but it is the light-mode purple
--pf-v5-c-button--m-primary--BackgroundColor-hover	#714099	white text 7.25:1, same note

--pf-v5-topology__node--Color is the real failure of the three. At 2.15:1 it is well under the 4.5:1 this issue cites, and it affects the broker diagram in dark mode. The two button backgrounds are a consistency problem rather than a contrast one, since white on them still clears AA.

What I would suggest

1. Treat the topology node colour as a separate, confirmable bug. It is a one line addition to .pf-v5-theme-dark mapping it onto the dark palette, and unlike the elements in this issue it can be verified from the stylesheet alone. Happy to open that as its own JIRA and PR rather than folding it in here, so it does not muddy this one.
2. For the elements actually reported here, table column headers, sort indicators and in row links, it would help to know the computed colours. If [~jthoursie] or anyone with a running console can read the resolved values off those elements in devtools, that pins whether they are inheriting PatternFly defaults or something in the Artemis layer.

I am glad to do the work once it is clear which layer owns the colour. I did not want to ship a patch to tokens I cannot show are the ones at fault.

---

What this PR actually changes

One line in .pf-v5-theme-dark, plus a comment recording the measurement:

--pf-v5-topology__node--Color: var(--artemis-global--primary-color-dark--100);

That is the third item in the table above, the only one of the three leaked tokens that is a genuine contrast failure rather than a consistency wrinkle. After it, the only tokens still set in the light block and absent from the dark one are the two primary-button backgrounds, where white text already measures 5.06:1 and 7.25:1, and a sidebar width.

Deliberately not included. A guard test asserting that every colour token in the light block is also overridden in the dark block would have caught this, and would catch the next one. I have not added it here: the stylesheet lives in the app package, which has no test runner today, and the only jest setup is in artemis-console-plugin, so the test would have to reach across packages. That seemed like the wrong thing to impose in a first contribution. Happy to add it wherever you would want it.

Not verified in a running console. I do not have a broker to point this at, so this rests on the stylesheet and the arithmetic rather than on a screenshot. The change is a single token mapping onto a value the surrounding lines already use, but if a maintainer with a running console wants to confirm the broker diagram before merging, that seems entirely fair.