feat(panels): lay the right panel out in sections instead of cards - #671

No control in the HUD styled its focus, so every one of them fell through
to the platform default ring. macOS paints that ring in the user's system
accent colour, so a user who set the accent to orange got a thick orange
band around a bar drawn entirely in mint and slate — heavier than any other
line in a 34px bar, and in a hue the HUD never uses.

It is not only a keyboard cost. `:focus-visible` matches on a programmatic
focus() and when the overlay window takes focus back, both measured here,
and this window loses and regains focus constantly. The ring reappeared on
a button the user had clicked with the mouse minutes earlier.

One rule on `.hudAnchor` covers the bar, the popovers and the notices, so a
control added later inherits it rather than falling through again. It sits
ahead of the specific rules in the file, so the language menu items and the
about actions — which deliberately answer focus with a background rather
than a ring — still win on source order.

Measured in the running HUD: a mouse click still draws nothing
(`:focus-visible` false, `outline: none`); Tab and focus() now draw
`solid 1px rgba(16, 185, 129, 0.75)` at 2px offset instead of the UA's
`auto 1px`; a language menu item still resolves to `outline: none`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…rner

A toast could only be waited out. That is fine for a confirmation and wrong for
an error: the 3s timer retires a long description before it has been read, and a
run of failures stacks over the editor with nothing to clear it.

Sonner ships a close button, so the work is where it puts one. Its default is the
START side — top-LEFT in a left-to-right UI — and half outside the box, hanging
off the corner like a badge. Nothing else here closes there: every dialog, pane
and inspector puts its cross inside the top end corner, and a dismiss control
that moves with the surface is one the eye has to hunt for.

Three things had to move together, which is why this is a stylesheet block rather
than one prop:

- the side, through sonner's own custom properties;
- the overhang, by dropping its `translate(35%, -35%)`;
- `top`, which sonner hardcodes to 0 instead of exposing as a variable, so it
  takes a rule on the element.

Flipped per direction rather than hard-coded to `right`. `ar` ships today and the
app does not set `dir` yet — this must not be the thing that breaks when it does.
The leading `html` in each selector is load-bearing too: sonner injects its
stylesheet at runtime, after ours, so an override of equal specificity would lose
on source order.

Inside the box, sonner's bordered opaque chip stops making sense — it reads as a
second surface floating on the toast — so the button is a plain icon that only
gains weight on hover, and the toast reserves `padding-inline-end` so a long
title cannot run under it.

The label comes from our own strings: sonner's default is an untranslated
"Close toast", and the rest of the app speaks 13 languages.

The tests pin what jsdom can actually see — the button exists, and it carries the
localized label — plus the three custom properties the placement rests on, in
sonner's stylesheet and ours. That last one is the real guard: on an upgrade that
renames them the override silently stops applying, the cross goes back to the top
left, and every other test stays green.

Also drops an unused `fireEvent` import in RightPanes.i18n.test.tsx that was
failing this branch's "Typecheck (tests)" job.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ll with the pane

The picker came inline with a `min(320px, 40vh)` cap and its own scroll, which
suited the image grid and cut the gradient tab in half. Tabs, preset grid and
the 240px-wide editor with its square wheel are about 600px tall (592px measured
at 1440x900), and the popover this replaced had already learned that a 460px cap
on that tab reads as "the gradient panel is gone": the content is there, below
an inner fold, behind a scroll nobody sees.

Inline in a pane that scrolls, the cap no longer buys anything. The picker now
takes the height its tab needs and the pane is the only scroller, so what sits
under the background section is one continuous scroll away and there is no inner
scroll to exhaust first. The image grid does not need a cap of its own either,
and the webcam's custom-background picker was already uncapped inline.

Checked in the running app: on the gradient tab the wrapper has no max-height
and no overflow, and wheeling over the pane reaches the motion blur slider at
its end.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The cross was meant to rest at slate-400 and brighten to slate-100 on hover,
through `group-[.toast]:` utilities in the Toaster's `classNames`. Neither ever
applied: sonner's dark theme sets the button's colour with
`[data-sonner-toaster][data-sonner-theme=dark] [data-sonner-toast] [data-close-button]`,
(0,4,0), and a Tailwind group utility is (0,3,0). The button showed sonner's
`--normal-text` instead, and the comment above the utilities said the colours
lived in index.css, which they did not.

They now do: the `html`-prefixed override that already places the button and
already outranks sonner at (0,4,1) sets the colour, at rest and on hover, from
the same slate scale as the toast's text through `theme()`. The utilities and
their comment are gone, and the comment on `closeButton` says where the colour
comes from and why it cannot come from `classNames`.

Only the dark theme needs covering: the Toaster is always `theme="dark"` on a
fixed near-black surface.

Checked in a browser against sonner's injected stylesheet: rgb(148 163 184) at
rest, rgb(241 245 249) on hover. The tests pin where the colours live, since
jsdom does not cascade.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The override clears sonner's chip border with `border-color: transparent`, but
only at rest. Sonner's dark hover rule,
`[data-sonner-toaster][data-sonner-theme=dark] [data-sonner-toast] [data-close-button]:hover`,
is (0,5,0), which beats the base override's (0,4,1), and it sets
`border-color: var(--normal-border-hover)`. So the ring the override exists to
remove came back under the pointer, around a cross that has no border at rest.

The hover rule already outranks sonner at (0,5,1) and reset only the
background; it now resets the border too.

Checked in a browser against sonner's injected stylesheet: the hovered border
was rgb(64 64 64) before, transparent after. A contract test pins the reset in
both rules.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…icker is inline

`.bgTrigger`, `.bgTriggerChip` and `.bgPopover` styled the collapsed trigger and
the floating panel the wallpaper picker used to live in. Bringing the picker
inline removed the markup that used them, and nothing in `src` references them
any more, so they are dead weight whose comments describe a UI that no longer
exists. The one thing worth keeping from the popover's rationale, why the
gradient tab must not be height-capped, already lives on `.bgInline`.

Also restores the doc comment above `useMemoCustomWallpapers`, taken from main,
which went out with `backgroundSwatchStyle` just above it although it belongs to
the hook.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The sections layout gave `.sliderCell .val` a muted colour but kept it in
`--font-mono`, while getopenscreen#667 moves the app's numeric readouts off the mono face to
the UI one with `font-variant-numeric: tabular-nums`. Two PRs landing with the
same kind of number in two different faces is exactly the inconsistency getopenscreen#667 is
there to remove.

The monospace face was doing one job here, keeping the value from twitching as
its digits change under a drag, and tabular figures do that job in the UI face.
The property comes after the `font` shorthand, which resets it.

Checked in the running app: the readouts compute to Geist, 11px, tabular-nums.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>