feat: ConfigureTokenPool changeset (EVM v2.0)

[futureproof1]

What

Adds the ConfigureTokenPool changeset (deployment/tokens/configure_token_pool.go): a family-agnostic changeset that applies small, targeted, idempotent configuration changes to existing EVM v2.0.0+ token pools:

• finalityConfig
• rateLimitAdmin / feeAdmin
• per-remote tokenTransferFeeConfig (partial)
• per-remote rateLimits (per-finality-bucket)

Every field below tokenPoolRef is optional: absent = leave on-chain state untouched; explicit values (zero address, disabled-with-zeros) clear things. Every write is read-compare-write — matching on-chain state emits zero transactions (no wasted gas, no MCMS predecessor conflicts). Output is assembled via the shared OutputBuilder, so MCMS-owned pools produce timelock proposals and EOA-owned pools execute directly.

To fill the one capability gap, this adds an optional adapter interface TokenPoolAdminAdapter (+ SetTokenPoolAdminsSequenceInput) and a new EVM v2 sequence SetTokenPoolAdmins, wired on the v2 TokenAdapter.

PR breakdown

This is PR#1 of 3:

• PR#1 (this): scaffolding + validation + apply orchestration, EVM v2.0.0+ support.
• PR#2: EVM 1.5.x / 1.6.x (wire the existing pre-v2 fee path; capability gating is already in place).
• PR#3: Solana 1.6.x.

Verify rejects resolved pool versions < 2.0.0 with a clear, scoped error.

Deliberate divergences from sibling changesets

• No counterpart / symmetry validation. Unlike SetTokenPoolRateLimits, each entry configures one pool's local view of a lane and never requires a counterpart section. Bidirectional use is supported (you may configure both sides in one changeset) but never required, and no symmetry is enforced — this is the changeset's core differentiator. Rate-limit validation is structural only (max 2 buckets, one per fastFinality flag, rate ≤ capacity, disabled ⇒ zeros); inbound still gets the +10% bump, identical to existing tooling.
• Fee config merges with current on-chain state, not defaults. A partial fee update (PartialTokenTransferFeeConfig.MergeWith over the on-chain config) never resets unrelated fields — intentionally different from the token-expansion flow, which merges with chain-agnostic defaults.

Testing

integration-tests/deployment/configure_token_pool_test.go:

• Verify-precondition table tests (duplicate/empty/unresolvable/structural rate-limit violations, invalid addresses, version gate).
• Single-feature apply + idempotency for finality, admins, fee (merge semantics), and rate limits (scaling + per-bucket skip).
• YAML round-trip pinning the tag contract, pre-v2 rejection, a combined multi-feature bidirectional apply, and an MCMS-owned-pool test (timelock proposal produced, executed, then a fresh-bundle re-apply emits zero proposals).

Full local verification green: go build + go vet across the deployment, chains/evm, and integration-tests modules; chains/evm v2_0_0 suites; and the full integration-tests/deployment package (48 pass, 0 fail). No core ref needed — the change is additive and Chainlink core compiles against it.

Ticket

[TOOLING]: add changeset to update token pool configs
Reference: #1931

[github-actions]

👋 futureproof1, thanks for creating this pull request!

To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team.

Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks!

[github-actions]

Metric	configure-token-pool-pr1	main
Coverage	69.6%	69.4%