fix: properly surface Treezor user rejection errors

[Olivier-BB]

Explanation

Treezor user rejection errors were not being surfaced clearly, which could result in uninformative error handling around rejected requests.

This change updates the relevant controller flows so Treezor user rejection errors are surfaced properly, and adds test coverage in both keyring-controller and transaction-controller to verify the behavior.

KeyringController now catches signMessage/signPersonalMessage/signTransaction errors (and conditionally signTypedMessage) and normalizes cancellation-like errors by recursively inspecting code, message, stack, cause, and originalError. TransactionController similarly detects cancellation-like errors (including a Trezor/"unknown error" string case), persists them as userRejectedRequest, and updates tests to assert the persisted error code.

The TransactionController tests for "cancelled"/"canceled" signing error normalization have been updated to use the KeyringController:signTransaction messenger action handler (rather than the legacy sign option) to properly exercise the error path, reflecting the current signing architecture.

References

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
Changes error shapes thrown from core signing and transaction-failure paths; consumers that matched on raw hardware error text or KeyringControllerError wrapping may see different errors, though behavior for genuine user rejections is more correct.

Overview
Hardware wallets (e.g. Trezor) often surface user cancellations as vague strings or wrapped errors instead of EIP-1193 userRejectedRequest (4001). This PR aligns signing and transaction failure paths so UIs and downstream code can treat rejections consistently.

KeyringController adds @metamask/rpc-errors and wraps signMessage, signPersonalMessage, signTransaction, and (when applicable) signTypedMessage so cancellation-like failures become providerErrors.userRejectedRequest with the standard MetaMask denial message, preserving optional data when present. Detection recurses through code, message, stack, cause, and originalError, including 4001, cancel/canceled strings, and failure_actioncancelled.

TransactionController adds parallel #hasUserRejectedMessage logic (including a Trezor “unknown error” string heuristic) and, in #failTransaction, persists and publishes the normalized rejection error on failed txs and transactionFailed events instead of opaque hardware errors.

Changelogs and broad test coverage document the new behavior; transaction signing tests mock KeyringController:signTransaction to exercise the path.

^{Reviewed by Cursor Bugbot for commit fc5e685. Bugbot is set up for automated code reviews on this repo. Configure here.}

[dawnseeker8]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved the merge conflicts in commit 1ef80fe. Two conflicts needed manual resolution:

1. keyring-controller/package.json: Combined the updated dependency versions from main with our added @metamask/rpc-errors dependency.
2. transaction-controller/TransactionController.ts: Kept our errorToPersist user-rejection normalization while incorporating the new receiptRevert logic added in main.

The yarn.lock was updated accordingly, and all 1,400+ tests across both affected packages continue to pass.

[owencraston]

@Olivier-BB please update this branch and fix CI so we can get this reviewed and merged.

[dawnseeker8]

@copilot resolve the merge conflicts in this pull request

[dawnseeker8]

@copilot resolve the merge conflicts in this pull request