studio: network selector wired to deploy-server network-by-name API (end-to-end multi-network)

[robercano-ghbot]

Context

Follow-up to #139. The deploy-server portion of #139 landed in PR #143: a server-side named network registry (network name -> RPC URL / chain id / optional deployer key / per-network deploymentParameters / per-network journal dir), configured via .env / a NETWORKS_CONFIG JSON file. The client selects a network by name only (opaque allowlisted key, ?network=<name> query param on POST /api/simulate, POST /api/deploy, and GET /api/deployment); RPC URLs and keys never come from client input. Per-network deployment/journal directories keep resume state from colliding across chains.

The studio is still single-network and does not yet use this API. This issue tracks the studio-side work to complete the end-to-end acceptance of #139.

Depends on

• The deploy-server network API landing first (PR feat(deploy-server): server-side multi-network support #143 against multi-network deploys end-to-end: network selection in deploy-server + studio #139). This is a hard dependency — do not start until feat(deploy-server): server-side multi-network support #143 is merged.

Scope (studio only, apps/studio)

• A network selector in the toolbar, populated from the deploy-server's configured networks (needs a way to enumerate available network names from the server; if the deploy-server does not yet expose a list endpoint, add that as a small deploy-server sub-task — network names only, never RPC URLs/keys).
• Simulate / Plan / Deploy and the Inspector operate against the selected network: all call the API with ?network=<selectedName>.
• The currently selected network is clearly visible in the UI and is shown in the real-deploy confirm modal (so an operator can't deploy to the wrong chain by accident).

Acceptance (completes #139's end-to-end acceptance)

• With two networks configured (e.g. two local Anvil instances on different ports), a user can deploy the same spec to both from the studio, with independent resume/journal state and correct per-network parameter values.

Notes

• Source issue: multi-network deploys end-to-end: network selection in deploy-server + studio #139 (kept open until this studio work lands).
• Server-side wire shape to target: ?network=<name> query param, bare spec body preserved for backward compat (see PR feat(deploy-server): server-side multi-network support #143).

[robercano-ghbot]

Resolved by the #139 wave — the full scope of this issue is already implemented and merged on main. Verified against origin/main (HEAD 3636318):

deploy-server (fixed contract, PR #143, merged 2026-07-16)

• apps/deploy-server/src/networks.ts: named-network registry (loadNetworksRegistry, resolveNetwork, listNetworks).
• ?network=<name> accepted on POST /api/simulate, POST /api/deploy, GET /api/deployment; unknown name → 400 { error: "Unknown network" }; omitted → server default (backward compatible).
• GET /api/networks → { networks: [{ name, chainId? }], defaultNetwork } — names/chainId only, never RPC URLs or keys.

studio (PR #145, merged 2026-07-17 — commits 50de3af, b0b09d5)

• apps/studio/src/deploy/networks-client.ts: fetchNetworks() (browser-safe, never throws; FALLBACK_NETWORKS_RESULT on failure).
• Toolbar network selector (data-testid="deploy-network-select"), populated from GET /api/networks, pre-selects the server default; selectedNetwork state threaded through useGraph.
• runSimulate(spec, fetchFn?, network?) / runDeploy(spec, fetchFn?, network?) append ?network=<encoded> when a network is selected, omit it otherwise.
• Real-deploy confirm modal names the target network (data-testid="deploy-real-network").
• Tests: apps/studio/test/App.network-selector.test.tsx, networks-client.test.ts, App.toolbar-layout.test.tsx.

end-to-end acceptance (PR #148, merged 2026-07-18, closed #139)

• Real two-Anvil multi-network e2e proving the same spec deploys to both networks with independent resume/journal state and correct per-network parameters.

An orchestrated implementer branched off origin/main for this issue produced an empty diff — there is nothing left to build. Closing as completed; no separate PR is warranted. (Autonomous loop note.)