feat: existing permission banner on permission picker

[mj-kiwi]

Description

Implement an existing-permissions banner in the permission picker to surface any permissions the user has already granted to a site for the requested chains/accounts.

This update depends on changes in the extension: MetaMask/metamask-extension#40995

Key Changes:

• Display existing permissions in a banner/section above the new permission request details

Related issues

Fixes:

Manual testing steps

Screenshots/Recordings

Before

After

Screen.Recording.2026-03-19.at.2.17.52.PM.mov

Pre-merge author checklist

• I've followed MetaMask 7715 Permissions Snaps Contributor Docs and MetaMask 7715 Permissions Snaps Coding Standards.
• 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 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
Changes the permission-request flow UI/logic by removing the blocking existing-permissions dialog and replacing it with a new banner driven by background permission lookups; this impacts core confirmation rendering and could regress gating/UX if the new status logic or wiring is incorrect.

Overview
Adds an existing-permissions banner to the permission confirmation screen that links out to a MetaMask “gator permissions” page, showing a warning when the user previously granted a similar permission type (stream vs periodic) and an info banner when prior permissions exist but are dissimilar.

Removes the entire core/existingpermissions dialog flow (content rendering, token-metadata formatting, UI components, and tests) and replaces it with a new ExistingPermissionsService.getExistingPermissionsStatus() in services/ that computes a single ExistingPermissionsState used during confirmation rendering.

Updates the permission lifecycle/orchestrator and handler types to fetch this status in parallel with the intro flow (with a non-rejecting promise) and pass it through to PermissionHandlerContent; updates i18n strings accordingly and adjusts snapshot tests for the new banner output.

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

[jeffsmale90]

This looks super good!

It's definitely less imposing than the full screen display.

[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.}

[jeffsmale90]

This is looking great! A huge improvement over the full screen.

[jeffsmale90]

This still requires that the link is the final part of the message, which will be problematic for some languages.

I think we can skip over this, but it might come back to bit us later.

[jeffsmale90]

nit: the distinction between "State" and "Status" here is confusing.

[mj-kiwi]

Due to our decision to use a different approach to display existing permissions #288, we are going to close this PR.