fix(evm): clear-sign 0x only when both traded assets resolve

[BitHighlander]

Replaces #470. Same goal, correct axis.

What #470 got wrong

#470 dropped Base, Arbitrum and Avalanche from the 0x chain allowlist because their chain ids truncate through uint8_t. Measuring the generated token tables showed that is not the real shape of the problem:

chain	token entries
Ethereum (1)	1924
BSC (56)	3
Polygon (137)	3
Base (8453)	0
Arbitrum (42161)	0
Avalanche (43114)	0

Two consequences:

1. Widening chain_id would not restore a single amount. There are no tokens for those three chains, so the lookup misses regardless of type. The truncation is a real latent bug, but it is not what makes the screens blank.
2. The allowlist leaves the same hole on the chains it keeps. BSC and Polygon carry three tokens each; any 0x swap there involving a fourth token renders "Unknown token value" exactly as Base would. Even Ethereum fails for tokens outside its 1924.

Chain identity was never the right question. The right question is whether the lookup resolved.

What this does

zx_isZxTransformERC20() and zx_isZxSwap() now claim a transaction only when both token lookups resolve. If either misses, the predicate returns false and ethereum.c falls through to the generic raw-calldata path — AdvancedMode-gated, bytes on screen. The owner can still sign; the device stops claiming it understood.

The refusal must live in the zx_is*() predicate, not the confirm: a false from ethereum_contractConfirmed() is treated as a user cancel and aborts signing (ethereum.c:740-745), whereas a false from ethereum_contractHandled() is the fall-through we want. Both decoders now share one resolver between predicate and confirm, so the two cannot disagree about what is displayable.

Properties this has and the allowlist did not:

• chain-agnostic — correct for all six chains and any future one, no list to maintain
• data-agnostic — correct whether the tables are incomplete today, expanded tomorrow, or stale in between
• zero flash cost — no table growth, no type change
• self-correcting — add Base tokens later and those swaps start clear-signing automatically, with no allowlist edit to remember

Tests

Ethereum.TransformErc20RequiresBothTokensResolvable covers both directions: two real chain-1 table entries (TUSD, TGBP) resolve and the transaction is claimed; an unknown input, an unknown output, both unknown, and each of the three zero-coverage chains all refuse.

Ethereum.TransformErc20RequiresCompleteCalldataForClearSigning (from #468) needed updating — it previously used zeroed token words, which under this change correctly no longer resolve. It now uses real addresses, so it still tests the streamed-tail boundary rather than passing for the wrong reason.

Note the Base/Arbitrum/Avalanche assertions now pass via the resolution gate while the allowlist still contains all six chains — the allowlist is untouched by this PR.

Scope

Does not touch #414: a payload that fits one chunk still carries transformations[] bytes the decoder never reads. Resolving both assets bounds what the trade can cost; it does not disclose the route.

Corrects the diagnosis on #455, which stays open as the type-correctness bug — and is a prerequisite for ever adding Base/Arbitrum/Avalanche tables, since uint8_t cannot distinguish 8453, 42161 or 43114.

Verified

ARM cross-compile in the pinned builder image; firmware-unit Ethereum.* 9/9 and the full xunit suite green; cppcheck clean under CI's exact invocation (0 findings); clang-format clean across CI's entire lint scope, not just the changed files.

[BitHighlander]

Correction to my comment above: I named the wrong owner for the residual.

I wrote that the in-buffer residual — up to 860 bytes of transformations[] the decoder never reads — belongs to #414. It does not. #414 is about the unread ABI offset word: a caller placing its real arguments elsewhere so the hardcoded positions display plausible-but-wrong values. That is misdirection, and it is fixed at head (canonical-offset pinning in zxswap.c:69-74 and thortx.c:70-74).

The residual here is non-disclosure, not misdirection: bytes that are never read or shown at all. Different failure mode, and it had no owning issue.

Now tracked as #473. Nothing about this issue's own closure changes — #444 was scoped to the streamed tail and #468 fixed exactly that.