Mark prose one way, whichever card it came from

A question's relation was an outlined block written as a DOM attribute; a
comment's was a washed range in the highlight registry. So the same fact —
this is the prose that card refers to — read as two different things depending
on which half of the sidecar it came from, and the pointer was blue for one
feature and amber for the other.

Everything is a wash now. ::highlight() accepts neither outline nor box-shadow,
so the outline was the treatment that could not be shared, and the wash is what
both can be. Three tones: amber for a live comment, which is the one place the
plan says somebody is waiting; the quietest accent for prose a decision
produced; and a strong accent for whatever the reader is pointing at, question
or comment alike. Colour says what is true of the prose, intensity says whether
you are pointing at it. Stacked by explicit priority so the pointer wins where
it overlaps a standing mark.

CSS.highlights is document-wide and painting sets it wholesale, so the two
stores could not each own it — the second to repaint would erase the first.
The registry is owned by marks.ts now: each store declares what it wants and
the union is painted. That also removes a hazard that had not fired yet, where
a question hover clearing data-plan-related would have wiped a comment's
standing mark.

The attribute survives as the fallback for a browser with no Highlight API,
and says so. The "current" variant and the plan-arrive keyframes are gone:
nothing has ever set that value.

Also found: the fallback abandoned every remaining mark when one key could not
be resolved, relying on the outer guard. Guarded per key instead.

Six tests on the shared registry and two on tone selection, each verified by
breaking the code it covers. Registration against CSS.highlights stays
unverified — there is none in the test runtime and no layout to measure, the
same reason the toolbar's placement has no test.