Refactor: minimize the usage of the static chains config

[katspaugh]

What it solves

New chains are popping up like mushrooms and the static chainId<->shortName config becomes a hurdle when adding new chain support via the config service.

I removed all the places where looking up a shortName in the static config was blocking the UI if the chain isn't there.

useChainId still relies on the static config to resolve a shortName from the URL faster, but it will now also look it up in the remote config. This means that loading a page on a chain that isn't in the config will redirect to the default chain (because the remote chains wouldn't be loaded instantly), but navigating to that chain via the menu will be still possible.

How to test

Test opening different chains, and also reloading the page on a given chain.

[github-actions]

Branch preview

✅ Deploy successful!

https://chains--webcore.review-web-core.5afe.dev

[github-actions]

ESLint Summary View Full Report

Annotations are provided inline on the Files Changed tab. You can also see all annotations that were generated on the annotations page.

Type	Occurrences	Fixable
Errors	0	0
Warnings	0	0
Ignored	0	N/A

• Result: ✅ success
• Annotations: 0 total

---

^{Report generated by eslint-plus-action}

[katspaugh]

@iamacook I've also removed our config and use that from safe-core-sdk-utils instead. It's better because it's now consistent with the Core SDK's chain support which we depend on already.
And Safe Core SDK's chain support is in turn consistent with safe-deployments because it checks for missing chains during the build (pretty neat!).

[francovenica]

LGTM

Being switching networks around, switching between safes, checking the switching the network in the safe creation, checking the "switch to x network" button when the wallet is in the wrong network.