fix: improve mobile alert details and notification navigation

[CoooderSan]

Summary

Improve the mobile alert-details experience and the notification deep-link flow.

• Make alert details responsive on narrow screens, including long titles, labels, messages, and detail values.
• Display alert details as a full-screen, theme-consistent view on mobile devices.
• Lock the page behind an open modal and prevent scroll chaining at modal boundaries.
• Open notification links directly on the target alert instead of briefly showing the dashboard first.
• Reuse an active PWA window when possible and mask stale iOS PWA snapshots during navigation.
• Render the alert-details loading state immediately for direct alert URLs.

Testing

• pytest -q tests/release/test_pwa_notification_navigation.py — 6 passed
• Added regression coverage for modal background scroll locking.
• Manually verified on iPhone:
  • notification deep links open the target alert;
  • alert details fit the viewport without horizontal overflow;
  • the background does not scroll after reaching the end of the details view;
  • the mobile alert-details theme is consistent;
  • direct alert URLs load the details view correctly.

Contributor License Agreement

After opening this pull request, comment exactly:

/sign-cla

You only need to sign once per CLA version. If you already accepted the current CLA.md, the CLA status check will pass automatically.

[Aidaho12]

Thanks for the PR — the mobile alert details and PWA navigation improvements look useful, and the overall direction makes sense.

Before we merge this, please rebase the work onto the current release/2.3 branch rather than main.

For IncidentRelay 2.3 we are currently doing a breaking AlertGroup/Incident API split, so main no longer represents the branch where active 2.3 development should be based. In particular, some AlertGroup API calls are moving from:

/api/alerts/...

to:

/api/alert-groups/...

Please:

1. Update your fork from upstream.
2. Create a new branch from upstream/release/2.3.
3. Reapply/cherry-pick your changes there.
4. Resolve any conflicts against the current 2.3 AlertGroup API and UI changes.
5. Open the PR against release/2.3, not main.

There are also a few things worth fixing while rebasing:

• normalize trailing slashes in frontend routing (/alerts/ should resolve exactly like /alerts);
• avoid duplicate syncAlertDetailsFromUrl() calls during auth/team bootstrap;
• add a same-origin guard in the service worker before client.navigate() / clients.openWindow();
• update AlertGroup API calls to the final 2.3 /api/alert-groups/... contract;
• keep /alerts/<id> as the browser/UI deep-link route.

Once the PR is recreated against release/2.3, it will be much easier to review and merge without introducing conflicts with the Incident Management v2 work.