fix(cast): report transaction types cast cannot encode

[mattsse]

cast tx --raw re-encodes the transaction it fetched, and alloy panics rather than invent an EIP-2718 encoding for a type it does not model. Arbitrum Nitro opens every block with an ArbitrumInternalTx (0x6a), so the command crashed the process on any Arbitrum One or Orbit rollup block, reachable with nothing more than a block explorer link. --lane made the same call and crashed the same way. cast tx and cast receipt on those transactions were unaffected, which is why this went unnoticed.

The fix follows what #16465 does for anvil's raw-transaction endpoints: route the response through the Foundry envelope, which knows the types Foundry supports, and report the rest as an error rather than reaching alloy's panic. Cast::transaction is generic over the network and cast tx instantiates it three ways, so this needs a small EncodeRpc2718 trait rather than a direct call. Only AnyTxEnvelope panics; OpTxEnvelope and TempoTxEnvelope encode every type they can deserialize, so their impls encode straight from the envelope while the AnyNetwork impl goes through FoundryTxEnvelope. That shape mirrors the existing per-network UIfmtSignatureExt. The conversion takes the whole RPC transaction rather than the envelope because the deposit path needs from.

Verified against live endpoints. On Arbitrum and Robinhood Chain the 0x6a now reports Cannot EIP-2718 encode transaction type 0x6a with the process healthy, and standard transactions on those chains and on Ethereum re-encode to bytes whose keccak is the transaction hash.

Regression coverage extends the network matrix from #16472, which deliberately left --raw out because of this panic. It asserts the command never panics, that standard types succeed and round-trip through keccak, and that a failure names the type; the Arbitrum and Robinhood entries reach the error branch because find_transaction takes the first transaction in a block, which on Nitro is always the internal one. Reverting the fix fails flaky_read_arbitrum on all six retries.

Two things this does not change. cast trace --raw panics identically on a transaction pasted in as JSON, at crates/cast/src/cmd/trace.rs:57; it is the same one-line fix but a separate path, so it is left for a follow-up. And a live Tempo 0x76 still cannot be encoded on the default network path, reporting Failed to deserialize tempo tx: missing field 'hash' instead of panicking. cast tx --network tempo --raw handles it correctly, and the AnyNetwork conversion belongs to #16465.

Stacked on #16472 for read_networks.rs. Independent of #16465, though the AnyNetwork impl here collapses into that PR's FoundryTxEnvelope::encode_rpc_2718 once both land.

AI assistance: written with Claude Code, including the code and tests, then verified locally against live Arbitrum, Robinhood, Ethereum and Tempo endpoints.

[github-actions]

✅ Changelog found

The deterministic check will validate the changed entry.