feat: Attach metadata when submitting a revocation to the permission provider snap

[V00D00-child]

Explanation

This PR extends the GatorPermissionsController to allow attaching metadata when submitting a revocation to the permission provider snap. Metadata includes:

• The transaction hash
• The block timestamp

References

Requires: feat: Store metadata when revoking a permission

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

Introduces metadata support for revocation submissions and updates flow to include transaction hash on confirmation.

• BREAKING: RevocationParams now requires revocationMetadata; submitRevocation/submitDirectRevocation forward it to permissionsProvider_submitRevocation
• Controller extracts transactionMeta.hash on transactionConfirmed and sets revocationMetadata.txHash; logs when hash is missing
• Tests updated to include revocationMetadata, validate refresh via permissionsProvider_getGrantedPermissions, and cover tx-hash propagation
• Changelog updated to reflect breaking change

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

[jeffsmale90]

Should we also add revocationMetadata to StoredGatorPermission (and as per my comments on the related PR, perhaps remove the isRevoked flag?

This would probably require some changes to how we load the permission from storage also, but IMO worthwhile,

[jeffsmale90]

is blockTimestamp a decimal string?

If that's the case, any reason not to represent it as a number? As is, it's a bit ambiguous.

[V00D00-child]

I dropped the block timestamp from the metadata. Seems unnecessary to pass this data to our Snap to store in profile sync when we can always fetch using the transaction hash.

[jeffsmale90]

It might be interesting to include the timestamp of when it was marked as revoked - especially if there's no hash 🤷

[jeffsmale90]

Shouldn't this be required? Is there a scenario where we want to persist the revocation status, but don't have revocation metadata?

As per other comments, I think we should name this explicitly revocationMetadata to make it clear to what it is pertaining.

[V00D00-child]

There is an edge case in extension where we call submitRevocation with only permissionContext. In this case, we would not pass any revocation metadata, so we have to make that value optional.

Here is a link to the code for more context: https://github.com/MetaMask/metamask-extension/blob/main/ui/hooks/gator-permissions/useRevokeGatorPermissions.ts#L176

Edge case: Before submitting a revocation transaction, we check whether the delegation is already disabled on-chain. If it is disabled, we don't submit a transaction; instead, we pass the permissionContext to the Snap revocation method.

[jeffsmale90]

That makes sense - I still think it makes more sense to set the revocationMetadata, but just make the txHash property optional. It reduces the data redundancy, making it more difficult to get inconsistent data, or to mis-interpret the data.

[V00D00-child]

Updated the RevocationParams to make revocationMetadata required and made txHash optional on RevocationMetadata.

[V00D00-child]

Making revocationMetadata required on RevocationParams will introduce a breaking change to the submitRevocation() interface. I will open a daft PR on the MM client to update calls to submitRevocation() to match the new interface.

[jeffsmale90]

As per previous comment - should we accept revocations where we don't have the metadata? In what scenario can this happen?

[V00D00-child]

In this case, where we are in the context of a handler that runs when a transaction is confirmed, we should accept revocations even when we don't have the metadata. Not sure why the hash on TransactionMeta type coming from transaction-controller is marked as optional, but I would expect it to be present when the transaction is confirmed.