feat(execution): register the deployed LunarBase and PancakeSwap Infinity CL executors

[zach030]

Registers three executors that are now deployed and active on the routers:

Protocol	Chain	Executor
lunarbase	BSC	0x99576B7C64Fe225785bd69E91fc9dC857Dd7AaA5
pancakeswap_infinity_cl	BSC	0xEaF480bc13D8Af32f19D7B780e484d60d277a27d
pancakeswap_infinity_cl	Base	0x6EbFE9c9b8Ed29260a1301db5F2a7fDf72899E25

For each one, this PR:

• adds it to executor_addresses.json, so the swap encoder registry builds the encoder on that chain
• lists it in deployment_registry.json and in the chain's table in contract-addresses.md
• adds a row to substreams/executors.sql

It also adds the BSC lunarbase entry to executor_deployments.json (no constructor args) and to the BSC list in deploy-executors.js. Both files already had the pancakeswap_infinity_cl entries.

Verification

• executorsActivationTimestamp on each chain's router is non-zero and in the past for all three executors, so the routers accept them now.
• The LunarBase runtime code on BSC matches LunarBaseExecutor built from main at 5f31593 with the Hardhat settings (solc 0.8.33, via-IR, 1000 runs, cancun). Only the metadata hash differs.
• On both chains, vault(), clPoolManager() and binPoolManager() of the PancakeSwap Infinity executor return the constructor args in executor_deployments.json. The runtime code matches the same build once the immutables and the metadata hash are masked.
• On a BSC fork at block 127995090, the LunarBase executor built from source was run through the router address. It covered both directions, with the router whitelisted and not, and with a blacklisted and a normal tx.origin. In all 8 cases the output equals the pool's own quote.
• check_executors.py passes. cargo nextest run -p tycho-execution passes for the deployment registry, swap encoder registry, LunarBase encoder and PancakeSwap Infinity encoder tests (22 tests).

🤖 Generated with Claude Code