[princedotrs]

Summary

Under the client-v3 feature, switchboard-on-demand exposes and returns the
Solana v2 AddressLookupTableAccount, so a pure Solana-3.x consumer can't use
the LUTs the client hands back. This PR points the client-v3 LUT type at the
v3-native solana_sdk::message::AddressLookupTableAccount, making the client speak
v3 end-to-end. 5 files, +14/−11, and a no-op for the v2 client feature.

Problem

client-v3 is meant for consumers on solana-sdk 3.x. But PullFeed::fetch_update_ix
(and the other client LUT helpers) return Vec<AddressLookupTableAccount> where, under
client-v3, AddressLookupTableAccount still resolves to the v2 type via a
solana_sdk_v2::address_lookup_table shim. A v3 caller that feeds those LUTs into
v0::Message::try_compile gets a hard type error:

error[E0308]: mismatched types
expected AddressLookupTableAccount (solana-message-3.1.0)
found AddressLookupTableAccount (solana-message-2.4.0)
note: there are multiple different versions of crate solana_message in the dependency graph

The two types are structurally identical ({ key: Pubkey, addresses: Vec<Pubkey> })
but carry different solana-pubkey majors (2.4.0 vs 4.2.0), so they don't unify.

Root cause

solana_compat.rs selects solana_sdk/solana_client/solana_account_decoder as v3
under client-v3, but the address_lookup_table module (and thus the exported
AddressLookupTableAccount) is still re-exported from solana_sdk_v2 with a comment
noting those crates "are not yet published for v3." That's no longer true — the v3
message LUT account is available at solana_sdk::message::AddressLookupTableAccount
(and MessageAddressLookupTableAccount already points there).

Fix

• solana_compat.rs — under client-v3, export the v3-native
  solana_sdk::message::AddressLookupTableAccount instead of the v2 shim. Keep the v2
  address_lookup_table module available for the on-chain state parser and
  program::id() only. Make to_message_address_lookup_table_account take the exported
  alias.

  // before (client-v3):
  pub use address_lookup_table::AddressLookupTableAccount;      // v2 shim → solana-message 2.4.0
  // after:
  pub use solana_sdk::message::AddressLookupTableAccount;       // v3-native → solana-message 3.1.0

• client/lut_owner.rs, client/transaction_builder.rs, client/utils.rs — the
  three files that imported the module-path type now use the exported alias.

• The 5 LUT construction sites build addresses element-wise
  (.iter().map(|a| a.to_bytes().into()).collect() instead of .to_vec()), since the
  bytes are parsed with the v2 state deserializer and rewrapped into the v3 type.

Compatibility

All changes are no-ops under the v2 client feature, where the exported
AddressLookupTableAccount already equals the module-path type. Only the client-v3
build changes behavior, and only to return the type a v3 caller expects.

Testing

• cargo check --no-default-features --features client (v2) — ✅ clean
• cargo check --no-default-features --features client-v3 (v3) — ✅ clean
• Real Solana-3.0 consumer (solana-sdk = 3.0.0) — cargo check and
  cargo clippy --all-targets -D warnings both clean; previously failed to compile.
• On mainnet: PullFeed::fetch_update_ix → v0 crank tx (update ix + feed LUTs bundled
  with downstream instructions) lands successfully across deposit/withdraw/borrow/repay
  flows against SwitchboardPull feeds.

Follow-up (not in this PR)

client-v3 still pulls a solana-sdk v2 subtree purely for the LUT state byte-parser
and program::id(). A later change could drop solana-sdk-v2 from client-v3 by using
solana-address-lookup-table-interface (already resolvable in v3 graphs), slimming the
dependency tree.