feat: integrate error tracking service with RPC handlers

[mj-kiwi]

Description

This PR improves error observability for the gator snap by introducing Sentry-based error tracking via MetaMask.

A new ErrorTracker abstraction is added, which reports errors using the snap_trackError method so that runtime failures inside snaps can be surfaced in Sentry. Since snap_trackError currently only supports a basic error payload and does not expose Sentry-specific features such as tags, relevant snap metadata (e.g. snap name) is embedded into the error message itself.

On the Sentry side, alerts are configured to filter errors originating from gator-permissions-snap and permissions-kernel-snap, and forward those errors to the team via email notifications. This allows us to proactively monitor snap errors and respond more quickly to production issues.

Related issues

Fixes: N/A

Manual testing steps

1. Trigger a known error path inside the gator snap (e.g. throw an error from a snap handler).
2. Verify that ErrorTracker calls snap_trackError with the expected error payload.
3. Confirm the error appears in Sentry with the snap metadata included in the error message.
4. Verify that the Sentry alert is triggered and an email is sent to the team for gator-related errors.

Screenshots/Recordings

Before

After

Email as below

Pre-merge author checklist

• I've followed [MetaMask 7715 Permissions Snaps Contributor Docs](https://github.com/MetaMask/snap-7715-permissions/blob/main/CONTRIBUTING.md) and [MetaMask 7715 Permissions Snaps Coding Standards](https://github.com/MetaMask/snap-7715-permissions/blob/main/docs/styleGuide.md).
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

---

Note

Medium Risk
Medium risk because it changes runtime error-handling paths in both snaps and introduces fire-and-forget calls to snap_trackError, which could affect observability and (if misused) send sensitive request.params to tracking.

Overview
Adds a shared SnapErrorTracker (packages/shared/src/utils/errorTracking.ts) that reports errors via snap_trackError, including structured metadata (snap name, method, URL/status/response data, and request params) embedded in the error message.

Wires this tracker into gator-permissions-snap and permissions-kernel-snap onRpcRequest handlers, wrapping execution in try/catch to capture errors asynchronously and then rethrow the original error (with the kernel snap preserving its processing-lock behavior).

Updates shared exports/tests and adds @metamask/snaps-sdk to packages/shared dependencies to support JSON error serialization.

^{Written by Cursor Bugbot for commit e6cc6b0. This will update automatically on new commits. Configure here.}

[MoMannn]

Also some cursor bug bot things to address

[jeffsmale90]

Looking really good, and we could probably ship it as is, but I've left a couple minor comments/thoughts/opinions.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

[jeffsmale90]

This looks good to me!

Because we are using this in multiple places, we're having to duplicate the setup logic in the two snaps, so in the future it might be useful to look at doing something like:

const errorTracker = new ErrorTracker({...});

// ...

errorTracker.trackErrors(() => {
  // logic in which tracked error may be thrown
});

I don't think we should do this now, but it might be a nice future tidy up.

I fixed the issues he mentioned on the PR and he is out this week.