feat: wire wallet_sendCalls approval flow end-to-end

[janek26]

Wire wallet_sendCalls approval flow end-to-end

After this PR, a dapp can call wallet_sendCalls and the user sees the existing SendTransaction approval screen with batch-aware UI. Approving executes the batch via delegation, stores the batch record, and returns the batch ID to the dapp.

What's included

• oRPC contract + handler – executeSendCallsBatch procedure callable from the popup via popupClient.wallet.executeSendCallsBatch.
• Provider callbacks – setBatch and getBatchByKey wired into handleProviderRequest with boundary validation. The provider can now store and retrieve batch records.
• Approval routing – wallet_sendCalls is added as a case in ApproveAppRequest, reusing the SendTransaction screen.
• Batch branch in onAcceptRequest – Detects batch requests via isWalletSendCallsRequest, calls the oRPC handler, and returns the batch ID on success.
• Batch-aware title – The approval header shows "Batch request: N calls on [chain]" instead of "Transaction Request" when reviewing a batch.
• i18n strings – batch_request_title, batch_call_label, batch_of_calls, batch_fee_note, batch_request_chain_unknown.

Design choices & review focus

• Reuses SendTransaction – Rather than a separate approval screen, batches go through the same flow. This keeps the UX consistent and avoids duplicating signing/gas/rejection logic.
• Gas estimation uses single-tx path for now – The TransactionFee component still receives a single transaction request at this point. Proper multi-call gas estimation is added in a later PR. This is good enough as a first pass since the delegation SDK handles gas internally.
• txRequest cast removed – The unsafe request?.params?.[0] as TransactionRequest cast is replaced with getTransactionRequestFromRequest(request) which handles both request types safely.

---

PR-Codex overview

This PR introduces support for batch processing of wallet send calls in the application. It adds new schemas, handlers, and UI components to accommodate the functionality, enhancing the transaction approval process.

Detailed summary

• Added case for wallet_sendCalls in ApproveAppRequest.tsx.
• Introduced executeSendCallsBatchHandler and executeSendCallsBatchContract.
• Created schemas for send calls in executeSendCallsBatch.ts.
• Updated handleProviderRequest to manage batch requests.
• Enhanced SendTransaction and SendTransactionInfo to handle batch requests and display appropriate UI elements.
• Updated localization files for new batch request messages.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[janek26]

• feat: multi-tx simulation and batch-specific approval UI #2238
• refactor: accept transactionRequests[] in TransactionFee and useGas #2237
• feat: wire wallet_sendCalls approval flow end-to-end #2236 👈 (View in Graphite)
• feat: add sendCalls execution logic and request normalization helpers #2235 : 1 other dependent PR (#2254 )
• feat: add batch store with validation and EIP-5792 types #2234
• feat: implement wallet_getCapabilities #2215 : 1 other dependent PR (#2216 )
• feat: add EIP-5792 inpage method stubs and provider upgrade #2214
• refactor: move pending tx cleanup from useEffect to store subscription #2250
• refactor: rewrite popup PendingTransactionWatcher to reactive useEffect pattern #2243
• feat: add chain-specific tiered polling schedule with timeout handling #2242
• feat: move pending transaction receipt checking to background service worker #2241
• master

---

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[DanielSinclair]

This is a SendCallsParams; was getTransactionRequestFromRequest missed here?

• [P1] Estimate wallet_sendCalls fees from the batch, not params[0] — /Users/daniel/Documents/GitHub/
  browser-extension/src/entries/popup/pages/messages/SendTransaction/index.tsx:301-303
  When this page is opened for wallet_sendCalls, request.params[0] is a SendCallsParams object, not a
  TransactionRequest. Passing it straight into TransactionFee means useEstimateGasLimit sees no to/
  data/value fields and falls back to the default transfer estimate, so every batch approval shows a
  misleading fee; for cross-chain batches it also reads gas data from activeSession?.chainId instead of
  the requested batch chain. Because executeSendCallsBatch later reuses
  selectedGas.transactionGasParams, this can also break execution when the batch targets a different
  network than the current session.
  • [P2] Use the batch chain when rendering and gating sendCalls approvals — /Users/daniel/Documents/
    GitHub/browser-extension/src/entries/popup/pages/messages/SendTransaction/
    SendTransactionsInfo.tsx:751-753
    Routing wallet_sendCalls through TransactionInfo here still leaves the approval sheet tied to
    activeSession.chainId: TransactionInfo simulates the request on the session chain, and the same file
    uses useHasEnoughGas(activeSession) to decide whether to block approval for insufficient gas. Since
    the provider accepts an explicit sendParams.chainId that can differ from the connected network,
    cross-chain batches will show the wrong network/simulation and can be incorrectly blocked or allowed
    based on another chain's native balance.