[ThePrimeShak]

Problem

Overlays rendered behind an open modal, and once lifted above it they still could not be clicked — clicking a toast button closed the modal instead of pressing the button. Reported for toasts, the habit widget dropdown, the bookmark three-dot menu, and the voice search language picker.

Root cause

showModal() does two separate things, and both bit us:

1. Moves the dialog into the browser top layer — no z-index can beat that.
2. Marks everything outside the dialog inert, so clicks pass straight through overlays and land on the dialog, matching the backdrop-close check e.target === dialogRef.current.

Changes

• Portal gains a topLayer flag (existing component, no new files). It renders into a host it owns, promotes it via the Popover API so it paints above an open dialog, and appends it to the topmost open modal dialog — the only non-inert region. A one-shot close listener moves the host back to document.body so a toast already on screen survives the modal closing.
• The host is created imperatively, not as JSX: React would otherwise own it as a portal root and throw NotFoundError on unmount once we re-parented it.
• Host defaults to pointer-events: none (it spans the viewport, so otherwise it would swallow every click); children opt back in. react-hot-toast already marks each toast wrapper > * { pointer-events: auto }.
• The toaster mounts at startup, before any modal exists, so every toast entry point re-raises the layer first.
• Applied to: toast layer, Dropdown, bookmark context menu, Tooltip, ClickableTooltip.
• Voice search language menu was a separate bug: a hand-rolled absolute popover clipped by the panel's overflow-hidden. Replaced with the Dropdown primitive, per AGENTS.md.

Also fixed here: every hover overlay in a modal revealing at once

In the shop, moving the pointer anywhere inside the modal revealed the "پیش‌نمایش" button on every wallpaper simultaneously.

Those buttons are plain CSS hover (opacity-0 group-hover:opacity-100), and each card does carry its own group. But group-hover compiles to:

.group-hover\:opacity-100:is(:where(.group):hover *)

which matches any hovered ancestor carrying .group, not the nearest one — and modalDialogVariants puts group on the <dialog> itself so modal-box can drive its open animation from group-open. The dialog wraps everything and covers the viewport, so entering it fired every group-hover inside.

The dialog now uses a named group (group/modal, with the four utilities as group-open/modal), so its marker is no longer .group. Naming the modal's group rather than the cards' is what fixes the whole class: group-open appears 4 times in one file, group-hover across 39 files — the leak affected every modal, not just wallpapers.

This one predates the branch; group has been on the dialog all along.

Deliberately left out

• canvas-edit-toolbar.tsx still portals straight to document.body. It belongs behind a modal — opening "add widget" from it should cover it.
• The sticker popover in advanced.modal.tsx is also a hand-rolled absolute popover prone to the same clipping, but it was not reported and is not inert, so it is left as-is.

Testing

• npm run compile
• npm test
• npx biome check src
• npm run build
• Modal open/close animation verified intact in the built CSS — all four group-open/modal rules, both @starting-style blocks included
• Manual check by owner: toast action button over the settings modal, habit widget dropdown, bookmark three-dot menu over the folder modal, voice search language menu, and the shop wallpaper hover

Note: #438 also edits modalDialogVariants. Whichever merges second will conflict; resolve by blending — that PR's shortened array plus group/modal in place of group.