[DEVREL-1425] fix: chunk setConfig to avoid calldata limits on L2s

[St0rmBr3w]

What does this PR do?

Chunks SetConfigParam[] into batches of 10 in EndpointV2.setConfig(), producing multiple smaller transactions instead of one large one. This prevents calldata/gas limit failures when wiring OApps across 20+ destination chains on L2s.

Why is this change needed?

When wiring OApps to many destinations, all config params (ULN + executor per chain) are encoded into a single setConfig calldata. With 20+ chains this exceeds calldata/gas limits on certain EVM L2s (Arbitrum, Optimism, etc.), causing lz:oapp:wire to fail.

The return type is already Promise<OmniTransaction[]> and the upstream consumer in ua-devtools already handles arrays with Array.isArray, so this is a zero-interface-change fix scoped to a single package.

How was this tested?

• pnpm build passes across all packages (protocol-devtools-evm + downstream consumers)
• Code review confirmed: chunkArray handles all edge cases (empty, undersized, exact multiples)
• Verified upstream consumer (buildOmniTransactions) already spreads OmniTransaction[]
• Verified setUlnConfig, setUlnReadConfig, setExecutorConfig all delegate to setConfig
• Dry run: npx hardhat lz:oapp:wire --oapp-config <config> --dry-run

Checklist

• Code follows style guidelines
• Self-review completed
• Single-package change — downstream consumers only need to bump @layerzerolabs/protocol-devtools-evm

[cursor]

PR Summary

Low Risk
Small, localized change that only alters how setConfig transactions are batched/constructed; main risk is callers expecting a single transaction or depending on the previous description string.

Overview
EndpointV2.setConfig() now chunks SetConfigParam[] into batches of 10 and returns multiple OmniTransactions (one per chunk) instead of encoding all params into a single setConfig call, reducing calldata/gas and avoiding L2 limit failures.

Adds a small local chunkArray helper and a CONFIG_BATCH_SIZE constant, and includes a changeset to release @layerzerolabs/protocol-devtools-evm as a patch.

^{Written by Cursor Bugbot for commit a225538. Configure here.}

[github-actions]

🧪 E2E Test Status

E2E tests are non-blocking and validate real blockchain interactions. Failures may occur due to network issues, RPC rate limits, or external service downtime.

Test Runs (Newest First):

• ✅ Run #6722 - Passed - 2026-02-19 16:40 (UTC)

[St0rmBr3w]

Why setEnforcedOptions isn't included here:

Two reasons. The calldata per entry is much smaller: compact (eid, msgType, options) tuples versus setConfig's ABI-encoded UlnConfig structs with variable-length DVN address arrays. At 20 chains setEnforcedOptions sits around 2-3 KB, well within L2 limits, while setConfig hits 8-20 KB. You'd need 100+ chains before enforced options runs into the same wall.

On top of that, setEnforcedOptions returns OmniTransaction (singular), not OmniTransaction[] — so chunking it means an interface change across IOApp, the EVM SDK, and all downstream consumers. Much larger scope than this single-package patch. Can be done as a follow-up if we ever need it.

[tinom9]

It'd be great to have this overridable by env var, such as in https://github.com/LayerZero-Labs/devtools/blob/main/packages/devtools/src/transactions/signer.ts#L180-L183.

[St0rmBr3w]

Perhaps we can mark it as a follow up PR? Trying to minimize package surfaces that I need to bump to unblock USDT0.

[clauBv23]

I agree, this should be configurable via env vars must be the easiest way