web: Modernize player UI (context menu, modals, panic screen, save manager)

[robinmiau]

Modernized the web player's built-in UI with several polish improvements across the context menu, modals, panic screen, and save manager.

• Context menu now has rounded corners and flips above/left of the cursor when it would overflow the viewport, matching browser behavior
• Context menu closes on scroll wheel when the cursor is outside the menu bounds
• Context menu items with checkboxes now render a proper SVG checkmark with a consistent left gutter
• When the Ruffle context menu is open, a second right-click (within an 8px movement threshold) now opens the native browser context menu
• Panic screen now matches the extension error screen, with details presented in a centered modal overlay instead of inline
• Software renderer detection improved to cover additional device types (Cpu, VirtualGpu), ensuring the UI warning modal triggers more reliably
• Save manager table now has a styled scrollbar and hover effects for rows and icons

Screenshots

Context menu

Old:

New:

Panic screen

Old:

New:

File manager modal

Old:

New:

[n0samu]

Looks great, thank you! I do want to preserve the attention-grabbing nature of the panic screen though - that's why we have the orange gradient background. Maybe adding an error icon to the initial panic screen would help with that?

[kjarosh]

I like the new design! Although I'd prefer to keep how the panic screen looks. We don't expect panicking often, so an attention grabbing gradient seems perfect and easily differentiates from the content erroing out.

[robinmiau]

@n0samu @kjarosh Would this be acceptable? I think it would still be an improvement over the current panic screen.

[kjarosh]

I think that looks better.

Can we split this PR into multiple ones? It's very difficult to review large changes. It would be nice to have a separate PR for each component, or if changes touch multiple components, they should be limited in scope.

[robinmiau]

@kjarosh This might be tricky, as all these changes involve the same files. Wouldn't there be merge conflicts if we split them into multiple PRs?

[kjarosh]

For instance: semantically, there's no reason for the behavioral changes of the context menu to be in the same PR as the UI redesign, is there?

It will be difficult to do a review, because we'll have to review everything at one go, and it will take considerably longer than in separate PRs.

Usually you'd do incremental changes, PRs can depend on each other and we can merge them sequentially too.

[robinmiau]

So should I start with a smaller PR and base the subsequent ones on that?

[kjarosh]

At the end of the day it's your call, I think this PR is splittable and we should do it because the review process will be easier.

[robinmiau]

Superseded by #23534, #23535, #23537, and #23538