refactor: improve GatorPermissionsController permission storage and syncronisation

[jeffsmale90]

Explanation

Makes the following changes to the GatorPermissionsController to improve storage and syncronisation of permissions data with Profile Sync service:

• constructor now accepts a configuration object, including supportedPermissionTypes and optional gatorPermissionsProviderSnapId and maxSyncIntervalMs.
• adds lastSyncedTimestamp (default -1); set when a sync completes successfully so initialize() can decide when to sync again.
• initialize() call after construction; triggers a sync if no sync has run yet or cached data is older than the configured interval.
• fetchAndUpdateGatorPermissions() now returns Promise<void>; callers should read from controller state. Concurrent calls share the same in-flight sync and no longer trigger duplicate operations.
• removes the GatorPermissionsMap JSON-serialized state (and related types and utils); permissions are now stored in state as a simple array. Sync is done by calling the gator permissions Snap via RPC.
• removes enableGatorPermissions() / disableGatorPermissions() and related actions; the controller is used as the single source for gator permissions when instantiated.
• removes support for the "custom" permission type from the public API and types.
• renames "Sanitized" permissions to "PermissionInfo" for clarity (this is the information required to show the permission in the UI)

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

Medium Risk
Broad breaking API/state changes and a new sync/caching flow can affect downstream consumers and UI assumptions. Core logic changes are mostly localized to the controller and covered by updated tests, but integration updates are required.

Overview
BREAKING refactor of GatorPermissionsController API and state. Construction now requires a config (including supportedPermissionTypes, optional gatorPermissionsProviderSnapId and maxSyncIntervalMs), removes the enable/disable flow and related messenger actions, and introduces initialize() to conditionally sync based on a persisted lastSyncedTimestamp.

Permission storage is redesigned: the JSON gatorPermissionsMapSerialized/map utilities and “custom” permission support are removed, replaced by state.grantedPermissions (array of PermissionInfoWithMetadata with internal fields stripped). fetchAndUpdateGatorPermissions() no longer accepts params, returns Promise<void>, dedupes concurrent calls via a shared in-flight promise, and uses a new executeSnapRpc helper to call the Snap.

Revocation-related API is tightened: pending revocations are accessed via state.pendingRevocations plus a new isPendingRevocation(permissionContext) action (case-insensitive check), and post-revocation refresh now always uses the controller’s internal fetch. Docs/changelog and tests are updated accordingly, including new unit tests for executeSnapRpc and revised mocks/fixtures.

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

[cursor]

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

[mj-kiwi]

Should supportedPermissionTypes be non-empty? It might be safer to enforce this at the type level to prevent invalid states.(e.g. [SupportedPermissionType, ...SupportedPermissionType[]])

[jeffsmale90]

I think it's valid to have no supported permission types - this would effectively mean Advanced Permissions is not enabled (which is the case up until now in main dist).