feat(ui): announce a download in a flyout (LAZ-999)

[r1chm8]

Adds the download flyout from LAZ-999: a panel that pops out beside the spine's download button when a download starts, and comes back on hover.

Why

Nothing in the UI confirmed that a download had actually started. The issue asks the flyout to do three things: confirm the download began, teach people where progress lives, and let them check it without losing their place.

How it works

The download button's click has to keep navigating to the Downloads page, so it can't become a Headless UI PopoverButton the way the notification bell is. Instead the flyout is a rich Tooltip, which gains two optional additions:

• open / onOpenChange(open, reason) — a controlled open state, so the flyout can show itself with nothing on the trigger. Omit both and hover owns it exactly as before.
• persistent — for a tooltip that shows itself rather than answering a hover: a press anywhere, or a neighbour in the same delay group opening, leaves it up. Escape still closes it. It's dropped the moment the pointer takes over, so from then on it behaves like any other tooltip.

Three hooks sit behind it in Spine/download_button/:

• useDownloadProgress — lifted out of DownloadButton so the button and the flyout share one aggregate. Rebuilt as two narrow subscriptions plus a useMemo: it previously returned a fresh object from inside useSelector, re-rendering on every dispatch while the download adapter pushes batched progress about once a second per download.
• useDownloadEta — samples one download's own received. Neither store field can give a per-file rate: downloads.speed is the aggregate across every download, and startTime is dead — nothing has written it since the init → started flip moved into the progress reducer, which is why SpeedOMeter already sorts on NaN there.
• useDownloadFlyout — announces, dismisses itself after 5s, hands over to the pointer. Seeded at mount, so a session resuming with downloads already in flight doesn't announce them as news.

The arrow moved into a shared OverlayArrow + .nxm-overlay-arrow rule, and the notification tray now uses it. The tray's beak was a rotated square — a 90° tip, so necessarily 2:1, which could never match the tooltip's 12×8 SVG. The tray's anchor gap also went 8 → 16 (8 + arrow height, matching the tooltip's own offset), and that is what actually made the two panels' edges line up.

Two bugs found on the way

• A disabled Tooltip wasn't inert. disabled only short-circuited the render; useHover, useFocus, useDismiss and useDelayGroup all still ran. The invisible tooltip claimed the delay group's currentId, the group closes whichever member isn't current, and that close cleared the real tooltip's pending open timeout — so the download button needed two hovers to show anything, its plain label included. disabled now reaches the interactions. ToolbarPanelButton uses the same tooltipDisabled trick, so this was latent there too.
• useDownloadEta couldn't measure a fast cadence. It replaced its stored sample on every update before checking the interval, so a run of updates closer together than the threshold never added up to a measurable gap. It only worked at all because the real adapter throttles to ~1/s.

What changes visibly

• A 320px flyout beside the download button: mod thumbnail, the file being downloaded, +N more for the rest of the queue, and time remaining. It shows a single "Download starting…" line until a name and a rate exist.
• The notification tray sits 8px further from the bell and wears the tooltip's beak instead of its own.