chore: prefer NEXT_PUBLIC_L2_RPC_URL over Infura so local forks receive traffic

lib/chains.ts:107-117 builds the RPC list with Infura first and the configured override second:

[chain.arbitrum.id]: [
  `https://arbitrum-mainnet.infura.io/v3/${INFURA_KEY}`,
  process.env.NEXT_PUBLIC_L2_RPC_URL,
].filter(Boolean)

viem's fallback() prefers the first entry and only rolls over on failure, so setting NEXT_PUBLIC_L2_RPC_URL makes the custom endpoint a backup to Infura rather than a replacement. Traffic keeps going to mainnet Infura.

That blocks local fork testing: pointing the explorer at anvil --fork-url … --chain-id 42161 has no effect. Blanking INFURA_KEY is not an option either — lib/chains.ts:21 throws without it.

Fix

When NEXT_PUBLIC_L2_RPC_URL (and the L1 equivalent) is set, put it first, or make it exclusive.

Unblocks testing flows that should not touch mainnet — treasury proposal creation and the transaction-lifecycle work in #739 both need it.

Related

#664 — wagmi config missing transports, same area.

Start in lib/chains.ts:21 and lines 107-117, then trace how viem's fallback consumes the RPC list. Verify that configured NEXT_PUBLIC_L2_RPC_URL values receive local-fork traffic for both L2 and L1 while the existing Infura configuration still works when no override is set.