feat: update notification-services-controller to support new Segment schema

[zelkibuilds]

Explanation

Implements the notification-services-controller portion of the notifications-analytics rework (PLAN §5): push events expose first-class analytics fields, and the in-app model gains a notification_subtype.

• §5.1 — Push parsing. web/push-utils.ts now reads the top-level FCM fields via toPushAnalyticsPayload instead of JSON-parsing data["data"] behind the isOnChainRawNotification gate. All push kinds (on-chain/platform/snap/feature-announcement) flow through one path; the §5.5 banner-display gap goes away.
• §5.2 — Push event payload. Added PushAnalyticsPayload (notification_id, notification_type, notification_subtype, profile_id?, chain_id?, deeplink?). Both push events (onNewNotifications, pushNotificationClicked) now carry [PushAnalyticsPayload]; createSubscribeToPushNotifications handler signatures updated to match.
• §5.3 — In-app subtype (model enrich). Added a required notification_subtype field to BaseNotification/INotification, populated in the processors via a new getNotificationSubtype(n) helper (on-chain kind / snap / features_announcement / platform fallback). Type-checking guarantees every processed notification carries it. id/type are
  unchanged.
• §5.5 — Removed the metadata parsing path and the nested blob.
• Inbox-on-push. The push payload no longer carries the notification body, so the onNewNotifications subscriber now re-fetches via fetchAndUpdateMetamaskNotifications() instead of inserting the payload.

Open questions

• Push payload shape (replace vs. augment). Per §4.4 the backend no longer ships the raw body in the FCM map, so the two push events now carry a flat PushAnalyticsPayload instead of INotification — a breaking change. Confirm a flat replacement was intended (not the 3 notification_* fields added onto the notification object).
• In-app model fields. We added notification_subtype to BaseNotification. Deferred: renaming id → notification_id (redundant with id) and adding a first-class notification_type (collides with the existing structural notification_type on API variants, and its value is unresolved — §2 says wallet_activity, §6.6 uses item.type). Confirm
  the desired end-state.
• Snap IDs. Snaps still get a client-generated uuid() in processSnapNotification — keep client-side or move upstream?
• Platform notification_subtype not returned by the inbox API (§4.3). The backend stores/stamps it (PR Enable and fix require-unicode-regexp issues #275 merged) but /api/v3/notifications doesn't expose it (verified against notify-notification-services@main), so the helper falls back to type (platform). Needs a follow-up to add it to the v3 response, then we regenerate schema.ts and flip
  the TODO.
• Feature-announcement subtype. Using features_announcement as the single value; per-campaign id pending the announcements team.

References

• Related to the notifications-analytics rework plan: notify-analytics-review/PLAN.md §5
• Consumer PRs to adopt the breaking event-payload change (forthcoming, pending the preview build + sign-off on the open questions):
  • metamask-extension — §7 (feat: new segment schema support metamask-extension#43132)
  • metamask-mobile — §6 (PR TBD)
• Depends on backend: §4.4 va-mmcx-notify-push-services for the top-level FCM keys (PR TBD)

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

High Risk
Breaking messenger and handler contracts require coordinated extension/mobile updates; push-driven inbox behavior now depends on API refetch instead of inline payload insertion.

Overview
Aligns notification-services-controller with the notifications analytics rework: push paths expose first-class Segment fields, and in-app notifications carry a normalized notification_subtype.

Push (breaking). onNewNotifications and pushNotificationClicked (and createSubscribeToPushNotifications handlers) now emit PushAnalyticsPayload (notification_id, notification_type, notification_subtype, optional profile_id, chain_id, deeplink) instead of INotification. Web push reads top-level FCM data via toPushAnalyticsPayload; the nested data["data"] / on-chain JSON parsing path is removed. Because FCM no longer includes the full body, the inbox subscriber re-fetches with fetchAndUpdateMetamaskNotifications() instead of inserting from the push payload.

In-app model. notification_subtype is required on BaseNotification / INotification, set in API, feature-announcement, and snap processors via shared getNotificationSubtype. getNotificationSubtype and toPushAnalyticsPayload are exported for clients.

^{Reviewed by Cursor Bugbot for commit 81b5f29. Bugbot is set up for automated code reviews on this repo. Configure here.}

[zelkibuilds]

needs validation

[zelkibuilds]

needs validation

[zelkibuilds]

Left some open questions in PR description + code

[cursor]

Snap subtype not backfilled

Medium Severity

fetchAndUpdateMetamaskNotifications reuses existing snap rows from state as-is, so persisted snap notifications never gain the new required notification_subtype field unless they are replaced by a fresh processSnapNotification path.

 

^{Reviewed by Cursor Bugbot for commit b1c77d8. Configure here.}

[cursor]

Invalid chain_id becomes NaN

Low Severity

toPushAnalyticsPayload sets chain_id with Number(data.chain_id) whenever the string is truthy, so malformed FCM values can produce NaN on the analytics payload instead of omitting the field.

 

^{Reviewed by Cursor Bugbot for commit b1c77d8. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 3 total unresolved issues (including 2 from previous reviews).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 81b5f29. Configure here.}

[cursor]

Invalid chain_id becomes NaN

Low Severity

toPushAnalyticsPayload sets chain_id with Number(data.chain_id) whenever the FCM string is truthy, without checking the result. A non-numeric chain_id value becomes NaN, which still satisfies the optional number type but breaks downstream analytics or routing that expect a valid chain id.

 

^{Reviewed by Cursor Bugbot for commit 81b5f29. Configure here.}