feat(ekubo-v3): support new TWAMM extension

[die-herdplatte]

A new version of the TWAMM extension was deployed, with the only noticeable change being that the cancellation fee for TWAMM orders was removed.
As this doesn't affect any logic in this integration, the required change is minimal.

Pair / Pool TVLs changed and certain E2E tests don't pass any longer due to the decreased liquidity in these cases.

A similar "state-dependency" issue came up with TWAMM pools.
At quoting time, the system time is used to guess a likely on-chain execution time.
Depending on active sale rates, already small differences between the actual and the estimated execution time can cause the tiny tolerance of 10 wei to be exceeded.

Ideally, you could pass a block number to testE2E and pass through an override timestamp to the TWAMM (and BoostedFees) instances somehow.
Note that none of the issues was introduced in this PR, they just surfaced now because pool states have changed.

---

Note

Medium Risk
Changes TWAMM quoting and on-chain event/state sync paths; mis-wiring v1/v2 addresses or pool-id parsing could break TWAMM pool tracking or quotes.

Overview
Adds dual TWAMM extension support for Ekubo V3: the former single TWAMM_ADDRESS is split into v1 and v2 contract addresses, each with its own quote/data fetcher, while sharing the same TWAMM ABI interface.

TwammPool now selects v1 vs v2 from the pool key’s extension and uses that deployment’s data fetcher and event emitter address. The pool manager subscribes to both TWAMM contracts for log routing, subgraph extension filters, and OrderUpdated pool-id parsing (extension in the reconstructed PoolKey matches the log’s contract). extensionType treats both addresses as Twamm.

Event integration tests are updated for v1 naming, a new v2 ETH/EKUBO TWAMM pool, and TWAMM order lifecycle cases grouped under VirtualOrdersExecutedAndOrderUpdated.

^{Reviewed by Cursor Bugbot for commit bac9a42. Bugbot is set up for automated code reviews on this repo. Configure here.}