feat(DepositAddressHandler): send depositAddress and inputToken on execute

[amateima]

What

The POST /deposit-addresses/execute endpoint gained new payload params. Relay two of them on every v3 execute:

• depositAddress — the funded address being swept. The API resolves which contract generation the address belongs to from this, instead of assuming the latest.
• inputToken — the funding token as { chainId, address }. Without it the API falls back to origin-native USDC, which mis-routes any non-USDC sweep.

Indexer data availability (checked before implementing)

Both values are already on the polled /deposit-address-transfers item, so nothing new is needed indexer-side:

Field	Source on the v3 item	Required?
depositAddress	top-level depositAddress (= transfer.to)	yes
inputToken.address	erc20Transfer.contractAddress	yes

Both are non-optional on DepositAddressTransferItemV3, and the indexer's v3 builder skips-and-warns any row missing a required durable field — so every served v3 item carries them. Both are forwarded verbatim, keeping Tron base58 end-to-end (the execute endpoint expects origin-chain-native encodings for origin fields).

Why neither field is gated

inputToken was previously behind ENABLE_EXECUTE_INPUT_TOKEN, because an API predating the schema change rejects an unknown param with 400 INVALID_PARAM (superstruct object() is exact). That reason is gone: both fields are now optional() in ExecuteRequestSchema on quote-api master, accepted-and-ignored on older contract generations. One bot build is therefore safe against every environment, so the flag is removed rather than extended to cover the second field.

ENABLE_EXECUTE_ERC20_TRANSFER_METADATA is untouched and stays gated.

bridgeOverride — the third field the endpoint now accepts — is deliberately not wired up here. It is an ops escape hatch to force a bridge instead of letting the API route, and needs its own config surface.

Config note

ENABLE_EXECUTE_INPUT_TOKEN: true in bot-configs/serverless-bots/across-config-5m.json becomes an unused key after this merges. Harmless (unknown env vars are ignored), but worth tidying in a bot-configs pass.

Drive-by test fix

The SIGNER literal in test/DepositAddressHandler.ts was not EIP-55 checksummed, so it never matched the handler's toAddressType().toNative() output. Three request-shape assertions were already red on master before this change; checksumming the constant fixes them.

Verification

• test/DepositAddressHandler.ts: 50 passing, 0 failing (master baseline: 48 passing, 3 failing — the checksum issue above).
• yarn lint: clean.
• yarn typecheck: the 3 pre-existing Dataworker.ts / validateRootBundle.ts poolRebalanceLeafCount errors are present identically on master and unrelated to these files; no new errors.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GzGPkq61Nh5zrpiXx3NY4R