Fix layering for saved page snapshot popover

[open-design-crew]

Summary

The saved page snapshot success popover appears at the wrong layer and position during the browser-assisted download page flow.

Current behavior

In the browser-assisted website extraction flow, after using the Browser menu action to download/save the page snapshot, a green success popover appears saying the page snapshot was saved. The popover is rendered across the split-pane boundary and overlaps both the left chat/composer area and the right browser content.

This makes the popover look anchored to the wrong surface and rendered at an incorrect z-index. It also covers controls in the composer area and part of the Browser page.

Expected behavior

The saved page snapshot popover should be positioned and layered consistently with the Browser/download flow. It should not straddle the left chat pane and right Browser pane or cover the composer controls.

Possible acceptable behavior:

• Anchor the success popover within the Browser pane near the download action.
• Use a standard toast region that does not overlap the composer controls.
• Ensure the popover z-index and bounds are scoped to the intended surface.

Steps to reproduce

1. Start a website/design-system extraction flow that requires browser assistance.
2. Open the site in the Browser tab.
3. Use the Browser More menu.
4. Click Download page / save page snapshot.
5. Observe where the success popover appears.

Notes

Screenshots were provided showing the Browser More menu with Download page, and the green Saved page snapshot (HTML + CSS) popover appearing across the lower split-pane boundary.

Why this matters

The snapshot save confirmation is part of the recovery path for blocked extraction. If the confirmation appears in the wrong layer and covers unrelated controls, users may not understand which action completed or what to do next.

[lefarcen]

Hey @open-design-crew[bot] — the screenshots make this one pretty clear.

I traced the current behavior to the page-snapshot success path: DesignBrowserPanel emits the snapshot toast upward, then FileWorkspace renders it through the shared Toast surface, which is styled as a global fixed toast (apps/web/src/components/FileWorkspace.tsx, apps/web/src/components/Toast.tsx, apps/web/src/styles/viewer/routines.css). That matches the split-pane overlap you're seeing, because the success message is being centered against the whole workspace instead of staying scoped to the Browser pane.

So this looks like a real UI bug rather than just a z-index tweak. Keeping bug + ux (and the existing community labels) feels right here. A good fix will either anchor the confirmation inside the Browser surface or route it to a toast region that already respects the Browser pane bounds.

[lefarcen]

If anyone wants to pick this up, comment /claim and we’ll mark it as yours.
The scope looks approachable for a community fix here.

[lefarcen]

Heads-up: PR #5423 is open against the same browser-assist surface.

It moves the pre-download guidance out of the global workspace toast and into the Browser panel beside the highlighted Download Page action, which should remove the cross-pane instruction overlay shown here. Keeping this issue open until that PR lands and we confirm the remaining browser-assist toast behavior is covered.