Re-introduce on-demand V3 pool fetch, gated to the indexer

[AryanGodara]

Description

Re-introduces #4560 (reverted in #4629), but gates the on-demand fetch behind a source capability so it only runs against the pool-indexer. The subgraph keeps its pre-#4560 behavior (misses deferred to the maintenance run), avoiding the prod fetch_liquidity latency spikes.

Changes

• Re-inroduce reverted commit from Revert "Fetch uncached V3 pools on demand so cold quotes find liquidity (#4560)" #4629
• Gatekeep this change only to the pool indexer. So doesn't affect prod networks at all.

How I tested

Proof that this does not regress fetch_liquidity latency. I tested with custom image. The screenshots are in IST (my timezone, so added UTC timestamps for verifiability)

1. mainnet staging: restart at 14:25 UTC (graph: 14:20 - 14:50 UTC)

2. ink prod: restart at 15:56 UTC (graph: 15:53 - 16:13 UTC)

3. arbitrum prod: restart at 16:10 UTC (graph: 16:07 - 16:27 UTC)

For scale

During the reverted #4560 these hit 10-13 MINUTES on the subgraph.

[claude]

Claude finished @AryanGodara's task in 1s —— View job

---

I'll analyze this and get back to you.

[jmg-duarte]

We observed the latency issues when repeatedly restarting services (due to me experimenting) did you test this scenario?

[AryanGodara]

We observed the latency issues when repeatedly restarting services (due to me experimenting) did you test this scenario?

I restarted the pods ~5 times in total. and compared the graphs (manually) and the metrics (via the MCP) to check each of these. And compared to the original graphs+metrics from when it was spiking.

and then did a negative test on staging again (flipped off pool indexer and set driver back to using subgraphs) to check if it spiked again.

also did trades on the FE (swap.cow.fi and dev.swap.cow.fi accordingly) to see if it spiked when having to look up new pairs again. None of these caused similar spikes, everything was in range.

This seemed enough to check the correctness.

[jmg-duarte]

LGTM