Registers `getAllowance` and `getTransactionReceipt` on the WalletConnect EVM
namespace so approvals resolve through the prerequisites flow like the other
EVM providers.

Both reads are implemented on the adapter, which already owns the universal
provider, rather than reaching for an EVM instance from the namespace - that
keeps the namespace actions as thin delegations and avoids casting the
WalletConnect provider to `ProviderAPI`.

They are served by the chain's node rather than the wallet.
`UniversalProvider.request` throws unless `universalProvider.connect()`
established the session, and this adapter drives the SignClient directly, so
it has no session of its own and every call failed before reaching the
network. Routing them to the wallet is not possible either: a session only
authorizes the methods it negotiated, and those are signing-only - `eth_call`
is not part of the eip155 RPC reference. WalletConnect's own provider makes
the same split.

Providers are memoized per chain, because the endpoint has to follow the
session's chain: a token address is meaningless on the wrong chain, and an
`eth_call` against it answers `0x`, which would read back as a zero allowance
and re-approve on every attempt.

Tron approvals sat on "waiting for approval" indefinitely, for three reasons.

A wallet that lets the user choose the allowance does not sign the transaction
it was handed: it rebuilds the call with the amount the user entered, reading
it from `__payload__`. Server-built transactions carry that field,
`transactionBuilder` does not return it, and ours was hardcoded to `{}` - so
TronLink had nothing to rebuild from, reported "Modification failed", and the
approve could never be signed. Wallets that decode `raw_data` themselves were
unaffected, which is why it looked like an inconsistency between providers.
The payload is derived from the transaction the node returned, so it cannot
describe a call other than the one that was built.

A refused broadcast resolves rather than throwing, and still carries a `txid`,
since the id comes from the transaction's own bytes. Taking it at face value
left the queue polling a transaction no node ever had. Refusals arrive in more
than one shape and never set `result` to `false` - it is simply absent - so
both `code` with a hex `message` and a capitalised node-side `Error` are
treated as failures, and the reason is surfaced instead.

Status was read with `getTransactionInfo`, which queries the solidity node and
answers nothing until the transaction solidifies, roughly 19 blocks behind the
head. The full-node lookup answers as soon as it is in a block, about 3s. The
result is also confirmed on `blockNumber`, because Tron sets `receipt.result`
to a failure code only on failure and may omit it on success.

OKX was the only wallet with a Tron namespace that registered no approve
actions, so its Tron swaps stayed on the server-driven flow.

Both devices sign a raw transaction on-device and work nothing out for
themselves, so they refused anything without a gas limit, and Trezor refused
anything without pricing. Server-built transactions carry both, but the
approve prerequisite is built on the client and leaves every gas field null,
so approving through either wallet failed outright.

The limit is estimated and the pricing quoted through the provider the signer
already creates, and only where the transaction supplied neither. Anything it
does supply is preferred and passed through untouched, so a server-built
transaction is still signed with exactly the gas it was created with and costs
no extra call.

The node's quote settles on one scheme rather than both, since a signed
transaction cannot carry them together: EIP-1559 wherever the chain quotes it,
and a legacy price otherwise.

The status poller advanced on a single receipt plus a single allowance read,
both answered by the wallet's RPC - which is a load balancer over several
nodes. One read agreeing with the receipt is not evidence that the node the
swap is submitted to has applied the approve block, so the swap went out
against state where the allowance was still missing and reverted, while a
manual retry moments later succeeded.

The allowance now has to read as sufficient on consecutive reads a few seconds
apart before the prerequisite is met, and a short read discards the reads
before it rather than being believed. It is the allowance, not the receipt,
that the swap depends on.

The receipt status was also compared against the exact string `0x1`, so a
wallet handing it over as `0x01` or as a number would have reported a
successful approval as failed.