perf(e2e): seed BananaFPC fee juice at genesis instead of bridging

[spalladino]

What / why

PR 2 of the round-4 e2e speedup effort. The fees-family suites pay a setup:bridge span (~48s ≈ 4 production slots per process) in FeesTest.applyFPCSetup, bridging fee juice from L1 to the BananaFPC via the gas portal (bridgeFromL1ToL2 = prepare-on-L1 + advance 2 blocks + a claim tx). That funding is pure setup plumbing — the fees tests snapshot the FPC's gas balance and assert deltas, they don't assert on the bridge itself.

Fee-juice balances are just public-data leaves at computeFeePayerBalanceLeafSlot(address), which getGenesisValues (world-state/src/testing.ts) already prefills for genesis-funded accounts — the same mechanism that funds the initial accounts and (already, on this base) the sponsored FPC. This PR seeds the BananaFPC's fee juice at genesis instead of bridging it during setup.

Note: the plan's premise that fundSponsoredFPC: true bridges was stale — the sponsored FPC has been genesis-funded since #19532 (setup pushes its deterministic address into the genesis-funded list). The remaining setup:bridge cost in the fees family is the BananaFPC bridge, which this PR removes.

Mechanism

• The BananaFPC address depends on the BananaCoin address and the FPC admin (the first setup account), and the accounts are generated inside setup() with random secrets — so the FPC address can't be precomputed by the test before genesis. Fixed deploy salts are added for BananaCoin and BananaFPC so both addresses become deterministic once the admin is known, and a computeExtraGenesisFundedAddresses(defaultAccounts) hook on SetupOptions runs after the accounts are generated and before genesis values are computed. FeesTest uses it to derive the BananaFPC address from the first account and add it to the genesis-funded list.
• The returned address flows through the existing initial-accounts path (addressesToFund → getGenesisValues), so it is funded with the same fee juice as an initial account (10^22) and automatically included in the L1 FeeJuicePortal feeJuicePortalInitialBalance (fundingNeeded) accounting — the portal's locked L1 balance stays consistent with total L2 fee-juice supply, exactly as for every other genesis-funded balance.
• applyFPCSetup deploys the FPC with the fixed salt and asserts the deployed address equals the seeded one, so any drift in the deterministic deploy params surfaces as a clear error instead of a downstream "insufficient fee payer balance". The bridgeFromL1ToL2 call is removed.
• The setup:bridge span wrapper is kept in place for the bridging that remains, so its disappearance from the fees setup hooks is the measured proof.

Scope decisions (site by site)

• FeesTest.applyFPCSetup BananaFPC funding → moved to genesis. Used by account_init, private_payments.parallel, failures, gas_estimation.parallel. This is the only funding that moved.
• FeesTest.mintAndBridgeFeeJuice (bridges to an arbitrary recipient) → kept. It fires in account_init test bodies that test the bridge/claim flow ("pays natively in the Fee Juice after Alice bridges funds") — real behavior under test.
• account_init FeeJuicePaymentMethodWithClaim / prepareTokensOnL1 → kept. Tests the atomic claim-in-deploy flow.
• Sponsored FPC → already genesis-funded via fundSponsoredFPC: true on this base; no change.
• cross_chain_messaging_test (fundSponsoredFPC: true) → already genesis-funded; its own cross-chain bridging harness is the behavior under test, kept.
• bench/client_flows_benchmark bridges to its BananaFPC → out of scope (benchmark harness, not in the fees e2e timing family), kept.
• Production/sandbox funding paths (cli, aztec sandbox) → untouched. The new hook defaults to unset; only the e2e fixtures opt in.

Expected effect

~48s × the number of fees processes that ran the FPC bridge in setup (account_init, private_payments, failures, gas_estimation). No C++, no new config, no change to production genesis roots.

Local verification

• single-node/fees/account_init -t 'pays privately through an FPC' passes; the span leaderboard for the run shows zero setup:bridge occurrences (was ~48s), while deploy:fpc/deploy:token remain. The FPC-paying test asserts the FPC's gas balance decreases by the fee, so the genesis funding is exercised end to end, and the deployed-address assertion held.
• single-node/fees/account_init -t 'after Alice bridges funds' passes with setup:bridge present in the test body, confirming the retained bridge/claim harness still works.

Measured numbers from a full CI run vs merge-base will be appended after a green run.