fix(HubPoolClient): handle zero-address SVM pool rebalance routes

[droplet-rl]

Motivation

A queued HubPool admin batch prunes pool rebalance routes by setting their destination token to the zero address, including the route for USDC on Solana (setPoolRebalanceRoute(34268394551451, USDC, 0x0)).

HubPoolClient's SetPoolRebalanceRoute event processing requires any SVM-destination event to carry (truncated) SVM USDC as the destination token and throws otherwise. A zero-address disable event for Solana therefore makes HubPoolClient.update() throw — permanently, for every consumer (dataworker, relayer, finalizer), from the moment the event is mined — since SetPoolRebalanceRoute is searched from deep history on every update.

Changes

• Exempt the zero address from the SVM USDC translation/validation and store it untranslated, matching EVM route-disable semantics. Downstream lookups already handle it: getL2TokenForL1TokenAtBlock returns undefined, l2TokenEnabledForL1TokenAtBlock returns false, and getL1TokenForL2TokenAtBlock no longer resolves the token from the disable block onwards.
• The mismatch throw is preserved for genuine non-USDC SVM routes (existing test still passes).

Testing

New test correctly disables an SVM rebalancing route covers: update does not throw on the disable event, the route still resolves at pre-disable blocks, and all three lookups correctly report the route as removed at the disable block. yarn hardhat test test/HubPoolClient.DepositToDestinationToken.ts: 9 passing.

🤖 Generated with Claude Code

[droplet-rl]

Thanks for the review, @pxrl. No inline comments to address, so no further changes from my side — CI (Builds/Lint/Test) is still running on 37f0b7e; once it's green this is ready to merge.

[droplet-rl]

🔎 View trace