Make the comment's controls legible in the dark

[asnunes]

Reported: hovering a comment in dark mode shows the copy and close controls, and
the contrast is bad enough that they cannot be made out.

What was wrong

The three controls on a comment — copy, the published link, close — were drawn
in faint, the app's quiet grey for icons. faint is held at 3:1 on purpose,
and the stylesheet says why: an icon carries its meaning in a label and is a
control rather than prose, so brightening it to 4.5:1 would flatten the one
distinction the quiet inks exist to draw.

That reasoning is sound, and it is written against the surfaces the rest of the
app is drawn on. The comment row is not one of them: it has a tint of its own,
comment-bg. Against that, the same grey lands at

• 3.58:1 in the dark — #6c747d on #141d29
• 3.26:1 in the light — #7f8791 on #eef3fa

Right on the floor, under a 14px glyph with a thin stroke. styles.test.ts
already measured this — comment-bg was in BEHIND_ICONS and the assertion is
>= 3 — so it passed the guard and could not be found on the screen. The number
was right and the bar was wrong.

What it does now

A comment-faint token, dimmed from the row's own ink rather than brightened
from the grey, so the controls still read as quiet parts of the comment instead
of chrome that wandered in:

--farol-comment-faint: light-dark(#4a7099, #6f93bf);

4.6:1 light, 5.3:1 dark. Hover is unchanged: full comment-ink on sunken,
which was already fine at 7.7:1.

comment-bg comes out of BEHIND_ICONS and gets its own assertion at 4.5:1,
plus one keeping the controls quieter than the prose they sit beside — lifting
them until they compete with the comment is the other way of getting this wrong.

Verified on screen

Same comment row, same element, photographed twice in dark mode: once with the
old grey forced back on, once with the new ink. The copy and check icons go from
melting into the row to legible.

Checks

Rust passes in full. On the web side App.test.tsx > light and dark > puts the choice on the root element fails on my machine with localStorage undefined;
it fails the same way on main untouched and passes on CI.

---

The one that was actually reported (added after the first review)

The above is real, but it is not what was being described. The complaint was the
armed close button — the "Sure?" confirmation — going unreadable on
hover, and that had nothing to do with tokens.

shadcn's ghost variant carries dark:hover:bg-accent/50 beside
hover:bg-accent. The two have different modifiers, so tailwind-merge does not
treat them as the same class: the pill's own hover:bg-comment-ink/90 replaces
the first, the second survives, and in the dark the dark: one wins. On hover
the background became accent-dim at half — a dark olive — while the text
stayed surface, near-black, because that override did match and stick.

Near-black on dark olive is 1.1:1. The word disappears.

Fourteen buttons in this app set their own hover background and every one of
them had it quietly taken away in the dark. The others only came out the wrong
colour; this one is the only place the text was dark, which is why it is the one
that broke.

Dropping the dark: rule lets each caller's hover apply, and makes the dark half
behave the way the light half already did. button.test.ts pins it, so a shadcn
update that puts it back fails rather than going unnoticed.

Verified on screen: the armed pill under a real pointer hover, before and after.
Before, the pill is an empty dark rectangle.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.