feat(bridge-ui-v2)!: bridge UI version 2.1

[KorbinianK]

This PR is huge, due to our changes in branching it was left pending for a while. Sorry about that. Original commit timestamps were lost when rebasing/cherry-picking.

Internal UI will be updated for testing asap.

New design for ETH/ERC 20

• Same stepper design as NFT bridge
• Smaller design adjustments for light mode
• Updated mobile dialogs for transaction view (NFT)

Refactor & Optimize

• Many utilities have been revisited, updated and refactored
  • Proper detection of bridged and canonical addresses
  • Client session caching to reduce repeated & redundant RPC calls
  • Timeout handling
  • Dynamic IPFS gateway config
  • More coming soon...
• Focus on re-usability of components: Both bridges share several core components now

Dependency update

• Updated to wagmi 2.6 -> lots of breaking changes
• Updated to viem 2.7
• Updated to walletconnect 4 (wagmi 2)

Note:
does not include new proof/multihop or invocation delay setup yet.

[dionysuzx]

hey @KorbinianK this should be okay to merge into main anyways (unstable). so long as this passes some manual testing we can go through, can we try to deploy this to prod?

basically, merging in the release-please PR after my PR merges (this one: #15782). i'll also need to quickly test out in my taiko-mono fork 🍻

---

PS: in regards to hotfixes and internal environment, we have a few ideas. I don't think we'll need a hotfix branch, because we should be able to just merge the hotfix to main, and merge a release-please PR. But that's only if we are never maintaining two divergent versions. If we need a hotfix setup later, we can easily add that so that we can patch a prod release somewhere further back than the HEAD of main. also, we can manage separate environment variables with vercel, so if we want to do deployments to "staging" (internal devnet) on every main branch, we can do that (and i think that makes sense, also can add e2e playwright stuff in that pipeline).

[KorbinianK]

@d1onys1us
I will fix the unit tests, then we can merge it. But a new (Katla) production deployment should be triggered by a release not PR, unless it specifically says "hotfix" in the title. But we can auto deploy to the internal/staging one.

Not sure what to do with breaking changes though (new ABIs and contract calls coming very soon) that rely on those being deployed, guess they need to go together in a release somehow? But going forward, we won't have too many of those breaking changes for the UI anymore I hope.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (a19922d) 26.93% compared to head (d40c55f) 26.93%.
Report is 19 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #15775   +/-   ##
=======================================
  Coverage   26.93%   26.93%           
=======================================
  Files         104      104           
  Lines        6140     6140           
=======================================
  Hits         1654     1654           
  Misses       4306     4306           
  Partials      180      180           

Flag	Coverage Δ		*Carryforward flag
eventindexer	17.22% <ø> (ø)
guardian-prover-health-check	36.13% <ø> (ø)		Carriedforward from 1ab96b4
relayer	37.97% <ø> (ø)

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.