Push receiver: read the declarative notification from the push event (Safari history fix)

[okieselbach]

Problem

First device test (iPhone, iOS 18.4+): pairing, the test push and the session-watch push all arrived with the right title and body, but every entry in the receiver's history was the generic placeholder ("Autopilot Monitor / New alert", type unknown, no link).

Cause: with "mutable": true Safari dispatches the regular push event with the proposed Notification in event.notification and event.data null (Push API draft). The worker read only event.data, got nothing, and stored the fallback entry.

Fix (web only, public/push/sw.js)

• The push handler reads event.notification first and shows the same content itself, so exactly one notification appears and the history entry is written at arrival. Other browsers still hand the raw JSON as event.data.
• A tap on a notification the platform displayed without the worker rebuilds the history entry from the Notification's data (same normalizer), so the history is complete either way.
• The click path's history write is now bounded like the push path's, so a stuck IndexedDB cannot keep a tap from opening the page.
• Tests pin both paths (lib/__tests__/pushSw.test.ts).

Verification

Web vitest, tsc and eslint green; see the CI run. Device check after deploy: open the receiver app, trigger a test push from Alerts › Push devices, the history entry must show title, body, facts and the portal link, and only one notification should appear on the lock screen.

🤖 Generated with Claude Code