feat: add devnet as a selectable network

[illegalcall]

Closes #6

Stacked on #7; review only the last commit until #7 merges.

Adds devnet as a build-time network (VITE_NETWORK=devnet) alongside paseo-next, with the devnet registry, endpoint, and gateways. Contract addresses resolve live from the selected network's registry. Adds a devnet deploy script and a DEPLOYMENT.md note (CDM v0.9.0+, para-1000 faucet, and deploy-before-build guidance).

Typecheck and both build variants pass. Devnet end-to-end needs the contract deployed there and a Desktop smoke test.

[illegalcall]

@ReinhardHatko Can you please review this?

[ReinhardHatko]

Reviewed the devnet commit only, as asked. The wiring is right where it counts, and I verified the values rather than taking them on trust:

• Registry 0x59b0245778917af55224e5f8fb55f7f8d452619f matches DEVNET_REGISTRY_ADDRESS in CDM's src/lib/env/src/registry.ts exactly.
• @parity/product-sdk-descriptors@0.8.0 does export ./devnet-asset-hub, and CDM's connection.ts imports the same devnet_asset_hub binding — the named export is correct.
• Gateway ordering matches CDM's DEVNET_IPFS_GATEWAY_URL (https://ipfs.io/ipfs) being first.
• Passing registryAddress explicitly is necessary, not belt-and-braces: it defaults to cdmJson.registry, and cdm.json:133 hardcodes the paseo-next registry. Without the override devnet would silently resolve against paseo-next.
• tsconfig.json already has types: ["vite/client"], so import.meta.env.VITE_NETWORK typechecks.

The one I'd want resolved before merge. fromLiveClient is strict — it returns err(ContractLiveAddressResolutionError) if an address can't be resolved and never falls back to the cdm.json snapshot. So a VITE_NETWORK=devnet build hard-fails at contract init unless @example/feedback is actually registered in the devnet registry, and the PR body says devnet deploy/resolve is unexercised. Can you confirm the contract is deployed there? If it isn't yet, this merges a build flag that throws for anyone who sets it. Worth a note in DEPLOYMENT.md either way, since the failure surfaces as a resolution error rather than anything that points at "nothing deployed on this network".

Needs a version floor. cdm deploy -n devnet requires CDM v0.9.0+ (the preset landed in #61, released 2026-07-16). This repo pins no CDM version — it's a global binary, not a devDependency — and the new DEPLOYMENT.md note doesn't state a minimum. I get unknown preset on v0.8.26, which was current three weeks ago. Please add the floor to the note.

DEPLOYMENT.md is half-migrated. The new block covers deploy; the rest of the flow is still paseo-only — cdm account map -n paseo (line 100), cdm account bal -n paseo (109), the faucet link hardcoding ?parachain=1500 (87), and the AccountUnmapped troubleshooting row (293). Since this app requires a Revive mapping before any contract call, a devnet user hits AccountUnmapped and gets pointed at the wrong network to fix it. The devnet equivalents (mapping, balance, para-1000 faucet) would close the loop.

Type erasure worth avoiding. loadDescriptor(): Promise<unknown> plus as any drops the descriptor type at all three call sites, including the generic fromLiveClient<TDescriptor> — on main, paseo_asset_hub was fully typed there. A type-only import for the annotation keeps the runtime import dynamic (so the single-metadata-chunk property you verified still holds) while letting the generic bind.

Question on shared state. cdm.json holds one network's registry, address, version and ABI, and cdm deploy -n devnet rewrites them. After a devnet deploy the committed manifest describes devnet while the default build targets paseo-next. The frontend tolerates this (always passes registryAddress, re-resolves addresses live), but it'd help to state the intended workflow — two manifests, or accept the churn?

Nits: the title says "selectable" but selection is build-time only and NETWORK.label only reaches a console.log — surfacing it in the UI would match the wording. And const raw in resolveNetwork shadows the multiformats/codecs/raw import; I checked and raw.code at line 222 is in a different scope so it's not a bug, but a rename would save the next reader the same check.

Sequencing: this still carries #7's commit, so it wants a rebase once #7 lands.

[illegalcall]

Addressed the review:

• Network selection is now a direct literal comparison on import.meta.env.VITE_NETWORK, so Vite folds the unselected branch. Both build variants ship only the selected network's metadata (dist/ ~1.6 MB either way).
• Descriptor type erasure removed (union type, no as any); raw shadow renamed; CDM v0.9.0+ floor, -n devnet commands, para-1000 faucet, and a deploy-before-build warning added to DEPLOYMENT.md, plus a note on the shared cdm.json workflow.

The devnet contract deploy and the Desktop smoke test are still pending on my side.

[illegalcall]

Went back through the full review; status:

• Metadata bundle: folded network selection to a literal comparison, so each build ships only the selected network's chunk.
• Type erasure: descriptor is a typed union now (no Promise<unknown> / as any), so fromLiveClient's generic binds.
• CDM version floor (v0.9.0+), -n devnet commands, and the para-1000 faucet are in the DEPLOYMENT.md note; the AccountUnmapped troubleshooting row is now network-aware (-n devnet on devnet).
• Shared-manifest workflow noted (deploy to one target, commit that manifest; the frontend passes the registry explicitly and re-resolves live).
• registryAddress stays explicit so devnet never resolves against the paseo-next registry.
• Nit: const raw was shadowing the multiformats/codecs/raw import again after the fold; renamed it.

Left the UI-label nit out for now (surfacing the network in a sticky-note board's UI is a bit out of scope). Still open on my side and gating merge: confirming @example/feedback is actually deployed to the devnet registry (fromLiveClient is strict with no cdm.json fallback) and the Desktop smoke test. This still carries #7's commit and will rebase once #7 lands.