Busy cursor persists ~30s after launch on GNOME/Wayland: activation token reaches Chrome but the startup sequence is never completed

### Summary

When Chrome is launched from a graphical launcher on GNOME/Wayland, the "busy"
(spinner) cursor keeps running for about 30 seconds. Chrome itself is up and fully
usable within a second — the window is mapped, responsive and correctly matched to
its app icon. Only the launch feedback is stuck, until it eventually times out.

Launching with `flatpak run com.google.Chrome` from a terminal never shows the
problem, because that path never opens a startup sequence in the first place.

This looks like the same symptom as #308 (closed, June 2024), which is still
reproducible almost two years later on a current GNOME.

### Environment

- Fedora 44, GNOME Shell 50.3, **Wayland**
- mutter 50.3, gnome-shell 50.3
- xdg-desktop-portal 1.22.1, xdg-desktop-portal-gnome 50.0
- Flatpak 1.18.0
- com.google.Chrome 150.0.7871.186-1, branch stable
- Runtime org.freedesktop.Platform/x86_64/25.08

### Steps to reproduce

1. Make sure Chrome is not running.
2. Launch it from the GNOME Activities overview or from a dock.
3. The window appears almost immediately and is usable.
4. The busy cursor keeps spinning for ~30 seconds regardless.

### Expected vs actual

**Expected:** launch feedback stops as soon as the window is up.
**Actual:** it stops only when the startup sequence times out. The duration is
always the same, independent of machine load or of how long Chrome actually takes —
which is what identifies it as a timeout rather than real work.

### What I verified

I traced the activation token through every hop:

1. **GNOME issues a token.** The problem only occurs on launch paths that create a
startup sequence. Launching from a terminal, which does not, never reproduces it.
2. **Flatpak forwards it into the sandbox.**
`XDG_ACTIVATION_TOKEN=test flatpak run --command=sh com.google.Chrome -c 'echo $XDG_ACTIVATION_TOKEN'`
prints the token. `DESKTOP_STARTUP_ID` is forwarded too.
3. **The token reaches the real Chrome process.** Launching with
`XDG_ACTIVATION_TOKEN=TEST-98765 flatpak run com.google.Chrome` and then reading
`/proc//environ` shows `XDG_ACTIVATION_TOKEN=TEST-98765` in the
environment of the browser process itself, not just of the sandbox shell.

So the token is delivered end to end, and is simply never used to complete the
startup sequence.

### Ruled out

- **Not #83 / #465 (misplaced `StartupWMClass`).** In the currently shipped
`.desktop` file, `StartupWMClass=google-chrome` is correctly inside
`[Desktop Entry]` (line 106, before the `[Desktop Action]` groups). The window is
matched to the app: a single dock icon, no ghost entry.
- **Not slow startup.** Chrome reaches a responsive window in ~0.2 s, whether
launched from the terminal or through its `.desktop` file with `gio launch`.
- **Not the user profile.** Same behaviour with a clean `--user-data-dir`.
- **Not the sandbox or the portals.** Both the app and the portals start normally,
and nothing is logged by gnome-shell during the stuck period.

### Workaround

Overriding the desktop entry with `StartupNotify=false` removes the stuck cursor
completely:

cp /var/lib/flatpak/exports/share/applications/com.google.Chrome.desktop \
~/.local/share/applications/
sed -i 's/^StartupNotify=true$/StartupNotify=false/' \
~/.local/share/applications/com.google.Chrome.desktop
update-desktop-database ~/.local/share/applications

The cost is losing launch feedback for Chrome — acceptable here only because that
feedback was already meaningless, staying on for half a minute after the app was
ready.

### Note on where this belongs

Since the token is delivered correctly all the way to the browser process, this may
well be an upstream Chromium issue in the ozone/Wayland startup-notification
handling rather than a packaging one, and I understand if it needs to be redirected
there. I am reporting it here because this is where users of the Flatpak will look,
because #308 was closed without a recorded cause, and because shipping
`StartupNotify=false` in the manifest is a mitigation available at packaging level
while upstream is sorted out.

I am happy to run further tests on this machine if that helps.

Start with the exported com.google.Chrome.desktop entry, especially StartupNotify, and reproduce through the GNOME launcher with flatpak run rather than a terminal launch. Trace XDG_ACTIVATION_TOKEN from the desktop entry into Chrome and compare that path with the documented terminal behavior. Done means identifying the missing startup-sequence completion or confirming a packaging mitigation that stops feedback when the window is ready.

Written by the indexing model from the issue text.