…ityRequested, encodeFinality (#233)

* feat(sdk): export FinalityAllowed, decodeFinalityAllowed, decodeFinalityRequested, encodeFinality from src/index.ts

* bump overrides

* sdk: export SELECTORS from public index.ts

* bump v1.5.1

* fixup! feat(sdk): export FinalityAllowed, decodeFinalityAllowed, decodeFinalityRequested, encodeFinality from src/index.ts

* update

---------

Co-authored-by: Andre Matos <[email protected]>

This pull request refines the way gas limits are calculated for EVM
chain transactions in the `EVMChain` class. The new approach provides a
more accurate and robust estimate by accounting for various worst-case
gas consumption scenarios that may occur during execution, rather than
relying on a fixed overhead. This helps ensure transactions have
sufficient gas under adversarial but valid conditions.

**Gas estimation improvements:**

* Enhanced the calculation of `execTx.gasLimit` in `EVMChain` to include
worst-case gas usage from ERC165 interface probes, additional buffer for
state updates, and EIP-150 forwarding overhead, based on the presence of
token transfers and receiver payloads.

Mirrors the v1.x branch pattern — on estimateGas failure, log a warning and return the unsigned tx without a pre-set gasLimit. Lets Explorer/MetaMask run their own estimation and surface the native revert-reason dialog in the wallet UI.

This pull request improves the robustness of gas estimation in the
`EVMChain` class by handling failures during the estimation process. If
gas estimation fails (for example, due to a `NoStateProgressMade`
error), the code now returns the transaction without a `gasLimit`,
allowing downstream tools like wallets to perform their own estimation
and provide better error feedback to users.

Gas estimation error handling:

* Wrapped the gas estimation logic in a `try-catch` block in `EVMChain`,
so that on estimation failure, the transaction is returned without a
`gasLimit`, and a warning is logged. This mirrors the behavior of the
v1.x branch and improves compatibility with external tools and wallets.
[[1]](diffhunk://#diff-cae1d5fb496ff335e72129fb79782365f7f977991d0e3cdb2f7bc062f2e060ceL1475-R1479)
[[2]](diffhunk://#diff-cae1d5fb496ff335e72129fb79782365f7f977991d0e3cdb2f7bc062f2e060ceR1489-R1494)

This pull request enhances the error-handling path for EVM chain
interactions in the SDK, particularly when using the Viem transport
provider. The main focus is to ensure that revert data from failed
contract calls is preserved and correctly decoded, achieving parity
between the Viem-based and ethers.js-based providers. It also adds
comprehensive tests to verify this behavior.

**Error handling and data preservation improvements:**

* Updated `ViemTransportProvider` in `client-adapter.ts` to walk the
Viem error chain and extract revert data, forwarding it in the JSON-RPC
error envelope. This enables downstream decoding of custom errors, such
as `TokenMaxCapacityExceeded`, by the SDK.
* Improved error message handling by preferring `.raw` revert bytes when
available, and using the EIP-1474 execution-reverted error code when
revert data is present.

**Testing and validation:**

* Added a new test suite in `fork.test.ts` that sends over-capacity
transactions through both the Viem and ethers.js providers, asserting
that the SDK decodes and surfaces custom errors identically in both
cases. This ensures functional parity and robustness of the error
decoding logic.
* Imported Viem client and transport provider in `fork.test.ts` to
support the new test cases.
[[1]](diffhunk://#diff-951371c0af67892627ef98d0745d3bf7260c57d65d83d22a84b666e13a1bb913R8)
[[2]](diffhunk://#diff-951371c0af67892627ef98d0745d3bf7260c57d65d83d22a84b666e13a1bb913R20)
* Included Viem's `BaseError` in the adapter for improved error
introspection.

## Summary

Align `EVMChain.feeToken` handling with the rest of the SDK's chain
families (Solana/Aptos/TON) by replacing `??` with `||` in the two EVM
sites that default `feeToken` to `ZeroAddress`.

**Why:** `??` fires only on `null | undefined`, so `feeToken: ''`
reached ethers unchanged — where `checkAddress('')` interpreted it as an
ENS name and reverted with `UNCONFIGURED_NAME`. Every other chain family
in the SDK already uses a
falsy-check (truthy-ternary on Solana/TON, `||` on Aptos), so an adapter
passing `feeToken: ''` as a "native" sentinel worked on 4 of 5 chains
and failed only on EVM with a confusing error.

`||` makes EVM treat the empty string the same as `undefined` → use
`ZeroAddress` (native), matching the rest of the SDK.

  ## Changes

  Two one-character edits in `ccip-sdk/src/evm/index.ts`:

  - `:1054` — inside `getFee(...)`, building the `Router.getFee` call.
- `:1337` — inside `generateUnsignedSendMessage`, driving approve + send
logic.

  ```diff
  - feeToken: populatedMessage.feeToken ?? ZeroAddress,
  + feeToken: populatedMessage.feeToken || ZeroAddress,
  - const feeToken = message.feeToken ?? ZeroAddress
  + const feeToken = message.feeToken || ZeroAddress

  Behavior change

  Exactly one input changes: feeToken === ''.


┌─────────────────────┬─────────────────────────────────────┬──────────────────────┐
│ Input │ Before │ After │

├─────────────────────┼─────────────────────────────────────┼──────────────────────┤
│ undefined / omitted │ ZeroAddress (native) │ ZeroAddress (native) │

├─────────────────────┼─────────────────────────────────────┼──────────────────────┤
│ '0xabc…' │ '0xabc…' │ '0xabc…' │

├─────────────────────┼─────────────────────────────────────┼──────────────────────┤
│ '' │ '' → ethers UNCONFIGURED_NAME error │ ZeroAddress (native) │

└─────────────────────┴─────────────────────────────────────┴──────────────────────┘

No other falsy strings exist in JS (only ''), so no other inputs are
affected.