feat: Store metadata when revoking a permission

[V00D00-child]

Description

Currently, during permission revocation submission, we store a boolean revoked flag to track the permission revocation status in profile sync. This PR extends the permission revocation submission process to allow storing additional metadata on the revocation transaction.

References

Required by(Core): Attach metadata when submitting a revocation to the permission provider snap

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

Introduces on-chain-aware revocation handling and metadata persistence.

• Profile Sync: Extends StoredGrantedPermission with revocationMetadata and updates updatePermissionRevocationStatus to persist/clear it; validates via zod; maintains 400kb limits
• RPC: submitRevocation now validates revocationMetadata, checks delegation disabled on-chain, optionally validates txHash via receipt status, then stores revocation with metadata
• Blockchain utilities: New BlockchainMetadataClient for on-chain checks; adds getTransactionReceipt with retry logic and validateTransactionReceipt
• Types/validation: Adds TransactionReceipt type and zTransactionReceipt; updates validateRevocationParams to accept revocationMetadata
• Wiring: Instantiates and passes BlockchainMetadataClient in index.ts
• Tests: Comprehensive unit tests added/updated for clients, RPC handler, and profile sync

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

[jeffsmale90]

A couple of general comments, and, I think a more architectural concern:

I think we should remove isRevoked from the stored permission, and use the existence of revocationMetadata to determine whether the permission is revoked to help improve data integrity.

[jeffsmale90]

we are trusting the timestamp provided by the caller.

We could accept just the txhash (instead of the metadata), fetch the block, and fetch it's timestamp. We are already fetching the tx receipt to ensure it's success.

I don't know how important it is that we have the correct block timestamp.

[V00D00-child]

I dropped the block timestamp from the metadata. If we ever need a block timestamp to present to the user in the MM client, we can fetch the tx receipt. Seems unnecessary to store block timestamp in the profile sync.

[jeffsmale90]

I don't think this is the correct place for this function - this class is a "Client that fetches token metadata directly from the blockchain".

[V00D00-child]

I was following the pattern of checkDelegationDisabledOnChain, which is also in this file, to maintain consistency. It's a bit confusing since the file name is blockchainMetadataClient but the class name in the file is BlockchainTokenMetadataClient.

My suggestion here:

1. Create a new class in the file called BlockchainMetadataClient
2. Move checkDelegationDisabledOnChain() and checkTransactionReceipt() into that new class

[V00D00-child]

I created a new class, BlockchainMetadataClient, and moved checkDelegationDisabledOnChain() and checkTransactionReceipt() into it.

[mj-kiwi]

I think the code here can never execute because the loop either returns, throws, or continues.

[V00D00-child]

Yes, the throw after the loop is unreachable, but it still satisfies TypeScript's control-flow analysis(ie, ts complains with Function lacks ending return statement, and return type does not include 'undefined') when we remove it, even though the code can't logically reach certain points.

[mj-kiwi]

All submitRevocation tests mock checkTransactionReceipt to return true, but there's no test for when it returns false

[V00D00-child]

I added a test case that captures when checkTransactionReceipt.mockResolvedValueOnce returns false which should throw an error - Error(Transaction ${txHash} was not successful. Cannot process revocation.)