feat: add per-side liquidity source parameters

[thesems]

Which Linear task is linked to this PR?

EXBE-580 (originating support ticket: TECHSUP-169).

Why was it implemented this way?

Adds an optional per-side liquidity-venue allow-list to the routing options:

• LiquiditySources — { source?: string[], destination?: string[] }, the venues each swap leg may execute against.
• RouteOptionsBase.liquiditySources — nested form, alongside the existing pools.
• ToolConfiguration.liquiditySourcesSource / liquiditySourcesDestination — flat form for the /v1/quote query surface.

Venue names come from Fly's liquidity-source list and are chain-specific (e.g. aerodrome-stable on Base). Venue-level filtering is Fly-only, so a side with a list set is reduced to fly — the same trade pools.deny already makes route-wide.

Why per-side rather than route-wide. The motivating case needs the destination-chain swap constrained to one venue while the source-chain swap stays unrestricted, and it has to work for a cross-chain swap into that chain as well as a same-chain swap on it. A single route-wide list (the pools.deny shape) can't express that, and exchanges.allow filters aggregators rather than venues.

Why two shapes. Mirrors pools.deny / denyPools exactly: /v1/advanced/routes takes nested options, the /v1/quote surfaces take flat query params. The nested interface carries the semantics; the flat keys {@link} to it rather than duplicating the docs.

Why placed on RouteOptionsBase. That is where pools lives, and it is the type the backend's presets and integrator routeOptionOverwrites config are declared against — so the parameter is settable per-integrator from config, not only per-request.

Why string[] and not an enum. Fly publishes 811 venue names and is the only authority on which are valid on a given chain. Enumerating them here would go stale and would move rejection from Fly (which can tell "unknown name" from "not on this chain") to us (which cannot). Deliberately left as opaque strings; the backend forwards them unchecked and maps Fly's rejection.

Additive and optional only — no existing field changes shape, so this is a minor release.

Visual showcase (Screenshots or Videos)

Not applicable — type definitions only.

Checklist before requesting a review

• I have performed a self-review and testing of my code.
• This pull request is focused and addresses a single problem.
• If this PR modifies the Types API or adds new features that require documentation, I have updated the documentation in the public-docs repository.

pnpm build (cjs/esm/declarations), eslint and prettier all clean; the four eslint warnings on src/api.ts are pre-existing and outside the changed ranges.

public-docs is not yet updated — the parameters need documenting on the quote/routes reference once the backend behaviour lands. Tracking that with the backend PR rather than here, since the user-facing description depends on the final validation and error semantics.

---

Consumed by lifi-backend exbe-580 (PR to follow). Suggest publishing a beta from this branch for the backend CI to build against, and holding merge until the backend PR is approved — then cutting the official release and bumping the backend catalog to it.