feat(cast): add --network flag to cast tx for network-specific raw encoding

[mablr]

Motivation

Replace the FoundryNetwork-based transaction_raw workaround with proper network selection via a new --network / -n CLI flag. This moves raw tx encoding back into Cast::transaction dispatching to the correct provider (Ethereum, Optimism, or Tempo) based on the flag.

Solution

• Add NetworkVariant enum (Ethereum/Optimism/Tempo) in foundry-cli opts
• use it w/ --network through CastSubcommand::Tx and provider construction
• Add test for Tempo raw tx encoding (tx_raw_tempo)

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[zerosnacks]

Nice, lgtm - pending @onbjerg's / @0xrusowsky

[zerosnacks]

Makes sense, would like to get @onbjerg's input & OK on this as we had a prior conversation about this when working on tempo-foundry; what is preferable is if we somehow have a central location where this is maintained; I don't have an issue with the current proposal.

Context:

foundry/crates/evm/networks/src/lib.rs

Lines 22 to 37 in ce69566

	#[derive(Clone, Debug, Default, Parser, Copy, Serialize, Deserialize, PartialEq)]
	pub struct NetworkConfigs {
	/// Enable Optimism network features.
	#[arg(help_heading = "Networks", long, conflicts_with = "celo")]
	// Skipped from configs (forge) as there is no feature to be added yet.
	#[serde(skip)]
	optimism: bool,
	/// Enable Celo network features.
	#[arg(help_heading = "Networks", long, conflicts_with = "optimism")]
	#[serde(default)]
	celo: bool,
	/// Whether to bypass prevrandao.
	#[arg(skip)]
	#[serde(default)]
	bypass_prevrandao: bool,
	}

[0xrusowsky]

personally i like it.
let's wait for @onbjerg to have a look before merging though

[onbjerg]

for cast this makes sense, however maybe it's worth thinking about:

1. can we autodetect the network in some cases? how would we do this? (e.g. a preliminary call to get chain id with eth transport -> use concrete provider)
2. for forge, it would probably make sense to have this in config

wdyt?

[zerosnacks]

for cast this makes sense, however maybe it's worth thinking about:

1. can we autodetect the network in some cases? how would we do this? (e.g. a preliminary call to get chain id with eth transport -> use concrete provider)
2. for forge, it would probably make sense to have this in config

wdyt?

Agreed; let's take this into consideration for the next steps @mablr and possibly do this as a follow-up