poa-app: per-chain contract config + generalized checkNetwork (#517)

[ClawDAOBot]

Summary

Resolves task #517 — the two architectural blockers PR #68 documented as out-of-scope for path A. Together with #68 (chainId-aware subgraph routing), this closes the read path for a wallet connected on Arbitrum or Gnosis: subgraph queries route per chain (#68) + write actions resolve chain-correct contract addresses (this PR).

What changed

poa-app/src/util/networks.js (new, 53 LoC)

• CONTRACT_ADDRESSES_BY_CHAIN_ID keyed on EIP-155 chainId
• getContractAddress(name, chainId) with polygonAmoy fallback
• isSupportedChain(chainId) for network-gate checks
• SUPPORTED_CHAIN_IDS exported for any UI that surfaces the list

Only polygonAmoy has AccountManager deployed today; other chains have empty entries so callers get an explicit console.warn instead of silent fallback.

poa-app/src/context/web3Context.js

• AccountManagerAddress now reads from getContractAddress('AccountManager', chainId) instead of the hardcoded polygonAmoy literal at the old line 53.
• checkNetwork() uses isSupportedChain(chainId) instead of the hardcoded chainId !== 80002 gate at the old line 60. Users on Arb / Gnosis no longer immediately get the wrong-network modal.

poa-app/src/pages/_app.js

• wagmi chains list expanded: [polygonAmoy, polygon, sepolia, arbitrum, gnosis]
• polygonAmoy stays as initialChain (only chain with deployed AccountManager today)
• RainbowKit now surfaces Arb / Gnosis as switch options

Relationship to PR #68

PR #68 (#460 path A — chainId-aware Apollo provider) is independent on disk; the file sets don't overlap. Either PR can land first. Together they form the read-path-multi-chain pair.

What this PR does NOT do (deliberate out-of-scope)

• Doesn't deploy contracts to Arb / Gnosis. The networks.js map has empty entries for those chains. Deploying AccountManager (and the other ~12 contracts referenced by web3Context) to Arb / Gnosis is separate ops work + admin-wallet-gated. This PR makes the FRONTEND ready for those deploys; it doesn't perform them.
• Doesn't change initialChain. Users connecting fresh still land on polygonAmoy (the only chain where actions work today).
• Doesn't add per-chain DD token / participation token addresses. Only AccountManager is hardcoded in web3Context.js; the other contract addresses come from the OrgRegistry (per-org, not per-chain hardcoded), which already flows via subgraph queries.

Acceptance check

The original #517 acceptance asked: "viewing an Arb org renders Arb data via the subgraph; user can wallet-switch to either chain via RainbowKit; contract write actions on the connected chain succeed (or fail with a meaningful 'chain not supported' message rather than a hard polygonAmoy gate)."

With this PR + PR #68:

• ✅ Wallet-switch via RainbowKit: works (chains list expanded)
• ✅ Subgraph queries route per chain: works (PR poa-app: chainId-aware subgraph routing (path A for #460) #68's apolloClient factory)
• ✅ checkNetwork() reports cleanly per supported-chain list: works (no more hardcoded 80002)
• ⚠️ Write actions on Arb / Gnosis: still fail at contract-call time because AccountManager isn't deployed there. The failure mode is now the wallet's "transaction will revert" preview, not a frontend modal. Improvement, not full fix.

Full Arb / Gnosis write support requires deploying the contract suite + populating CONTRACT_ADDRESSES_BY_CHAIN_ID[chainId] with the resulting addresses. That's a separate ops task.

Test plan

• Deploy preview env w/ existing NEXT_PUBLIC_SUBGRAPH_URL only set — verify polygonAmoy flow unchanged
• Connect wallet on Gnosis — verify checkNetwork() does NOT immediately open the wrong-network modal; verify subgraph read-side works (requires PR poa-app: chainId-aware subgraph routing (path A for #460) #68 also merged + NEXT_PUBLIC_GNOSIS_SUBGRAPH_URL env var)
• Attempt a write action on Gnosis — verify it fails at wallet preview (no AccountManager deployed yet), not at the network modal

🤖 Generated with Claude Code