Microsoft Edge (Flatpak, `com.microsoft.Edge`) fails to load certain JavaScript-heavy web applications, like fidelity.com...but fine with .deb

## Summary
Microsoft Edge (Flatpak, `com.microsoft.Edge`) fails to load certain
JavaScript-heavy web applications, like fidelity.com, Venmo.com, and Discover.com showing a generic "Can't open this
page" / renderer error (Error code: 5), while the same sites load
correctly in the same package's Chromium (also Flatpak) and in a
natively-installed Edge (.deb) on the same machine.

## Environment
- OS: PopOS 24.04 LTS / Cosmic
- Kernel: 7.0.11-76070011-generic
- GPU / driver: 00:02.0 VGA compatible controller: Intel Corporation Meteor Lake-P [Intel Arc Graphics] (rev 08)
DeviceName: VGA compatible controller
Subsystem: Intel Corporation Meteor Lake-P [Intel Arc Graphics]
Kernel driver in use: i915

- Desktop environment: COSMIC (default PopOS shell)
- Display server: tested on both Wayland and X11 (via --ozone-platform=x11) — same result on both
- Edge Flatpak version: 151.0.4129.59 (as reported in-app) /
151.0.7922.72 (as reported in outbound request User-Agent strings —
these two version strings disagree, may be worth noting separately)

## Affected sites
Reproducible on multiple, unrelated financial-services web apps:
- fidelity.com (login.fidelity.com / digital.fidelity.com)
- paypal.com
- discover.com

Not site-specific — no shared CDN, JS framework, or vendor across these
three as far as I can tell. Simple/static pages load fine; the pattern
suggests something about JS-heavy, complex single-page-app-style sites.

## Steps to reproduce
1. Install Edge via Flathub: `flatpak install flathub com.microsoft.Edge`
2. Launch Edge (tested both via dock/launcher icon and via terminal:
`flatpak run com.microsoft.Edge`)
3. Navigate to https://login.fidelity.com/ftgw/Fidelity/RtlCust/Login/Init
4. Page begins to load, then immediately fails with "Can't open this
page" / Error code: 5, before login can be attempted

## What I've ruled out
- **Not a network/DNS error** — the error screen is Chromium's generic
renderer-crash page, not a `net::ERR_...` connection failure
- **Not Wayland/Vulkan-specific** — same failure with
`--ozone-platform=x11`, which removes the Wayland+Vulkan code path
entirely (this combination does log an unrelated ERROR on Wayland:
`wayland_surface_factory.cc:249 '--ozone-platform=wayland' is not
compatible with Vulkan` — but the failure persists even when this is
eliminated)
- **Not GPU/WebGL-related** — `edge://gpu` reports WebGL as hardware
accelerated
- **Not launcher-specific** — fails identically whether started from
the dock icon or from a terminal with `flatpak run`
- **Not general Flatpak sandboxing** — a separately-Flatpak-installed
Chromium (`org.chromium.Chromium`, non-Microsoft) loads the same
pages without issue on the same machine, same session
- **Not reproducible via `--enable-logging=stderr --v=1`** — verbose
logging shows a completely clean page load (fonts, LaunchDarkly init,
tracking-prevention blocking third-party trackers as expected, no
ERROR lines related to rendering) with the browser process remaining
alive for 10+ minutes afterward — despite the on-screen error
appearing during that same session. This suggests the renderer may
be killed at the kernel/sandbox level (OOM or seccomp denial) rather
than failing through Chromium's own error-handling/logging path —
worth checking `dmesg` output

Reproduce the failure with `flatpak run com.microsoft.Edge` using the Fidelity URL, then compare it with Flatpak Chromium and the native Edge package as described. Check `dmesg` for kernel or sandbox messages around the renderer failure; done means identifying a reproducible Flatpak-specific cause or the evidence needed to hand it to the relevant maintainer.

Written by the indexing model from the issue text.