breaks money

Solana channel sync fails for the whole batch when one payout is a version 1 transaction

sync/transfers/trigger/chains/solana/bitquery-channels/query.ts (line 102) fetches the candidate payouts with connection.getParsedTransactions(chunk, { maxSupportedTransactionVersion: 0 }). @solana/web3.js throws for the whole batch if any one entry comes back as an error, so a single version 1 payout makes transformResponse throw and none of the channel payouts in that Bitquery response get recorded on that run.

This already happens on the payment-channels program. Of the last 200 successful transactions on CHNLxYvVA28MJP9PrFuDXccuoGXAx7jBacfLEkahyGsX, 2 are version 1, for example a payout from a now-closed channel vault (6LKxx951yhF9J2jxgduUuwaG7xFUyZvuRJGvfiYPwbxh) paying 0.001 USDC to each of two recipients: 2SmL3M6ucn5vxSwc2nFGE37YBP2HVxaKDksY7qpkNeYQKpipYApVBnbjVgwhvufqg4ZZRYDqjdFPuT8WyXfF7GkS (slot 462245428). Its sender account is closed, so findChannelSenders keeps it as a candidate and it goes into the batch.

Version 1 transactions are a large share of mainnet now (127 of 288 non-vote transactions, about 44%, in a block I sampled today), so this depends only on which wallet or SDK built the transaction.

• sync/transfers/trigger/chains/solana/bitquery-channels/query.ts:102

getTransaction(<v1 signature>, { maxSupportedTransactionVersion: 0 })  -> error -32015 "Transaction version (1) is not supported by the requesting client"
getTransaction(<v1 signature>, { maxSupportedTransactionVersion: 1 })  -> the transaction (version 1, meta present)

Fix: maxSupportedTransactionVersion: 1, plus @solana/web3.js 1.99.0 or later. The lockfile has 1.98.4, which rejects a version 1 answer even when asked for it (its response check only allows 0 | 'legacy'; 1.99.0 adds 1).