feat(cct-sdk): Add get token pool state config solana op

[mervin-link]

What

• DAPP-10574
• Add getTokenPoolState to the Solana CCT token manager for Burn/Mint and Lock/Release pools
• Return serialized pool configuration and pool-type-specific state fields

Why

• Enable SDK consumers to inspect canonical Solana token pool configuration without manually fetching and decoding the state account

Note

• Custom pool program address does not recognize lock-release type so lock-release fields will not be included.

[vercel]

You must have Developer access to commit code to Chainlink Labs on Vercel. If you contact an administrator and receive Developer access, commit again to see your changes.

Learn more: https://vercel.com/docs/accounts/team-members-and-roles/access-roles#team-level-roles

[aelmanaa]

Heads-up on a maintainability angle that crosses core and CCT — not a blocker for this PR, but worth deciding before the next CCT read op lands.

The token-pool state account is decoded in two places that have to agree byte-for-byte: core (solana/index.ts — getTokenPoolRemotes uses tokenPoolCoder.accounts.decode) and CCT (programs/token-pool.ts — decodeTokenPoolState). Both build the same TOKEN_POOL_IDL = { ...BURN_MINT_IDL, types: BASE.types } merge and the same BorshCoder. The IDL data files themselves are already shared (both import solana/idl/1.6.0/{BASE,BURN_MINT}_TOKEN_POOL.ts), so the account layout is single-sourced and won't drift. But the merge recipe + coder construction are duplicated, and the version pin (1.6.0) is independent in each — those can drift.

The two obvious fixes are both wrong here: importing core's coder would force a runtime import of the 1929-line solana/index.ts into the CCT op layer (which today only type-imports core — that's the load-bearing separation), and pushing the read into core would fatten getTokenPoolConfig for every core user who never touches CCT.

A third option that honors both separation and DRY: extract the merge + coder into a small neutral leaf under solana/idl/ (e.g. token-pool-coder.ts) that depends only on @coral-xyz/anchor and the IDL data files — never on solana/index.ts or cct/**. Core and CCT both import it; each keeps its own result projection (core's 4-field view, CCT's 15-field view). The load-bearing types-splice comment lives once, in one place.

With more CCT read ops coming (registry state, chain config, rate limits), establishing the leaf now — at the first duplication — is cheaper than retrofitting it at the third. If it feels premature for this PR, the fallback is just adding the merge comment to both copies and aligning the version pin. Either way, worth a decision before the next read op duplicates the coder again.

[mervin-link]

Heads-up on a maintainability angle that crosses core and CCT — not a blocker for this PR, but worth deciding before the next CCT read op lands.

The token-pool state account is decoded in two places that have to agree byte-for-byte: core (solana/index.ts — getTokenPoolRemotes uses tokenPoolCoder.accounts.decode) and CCT (programs/token-pool.ts — decodeTokenPoolState). Both build the same TOKEN_POOL_IDL = { ...BURN_MINT_IDL, types: BASE.types } merge and the same BorshCoder. The IDL data files themselves are already shared (both import solana/idl/1.6.0/{BASE,BURN_MINT}_TOKEN_POOL.ts), so the account layout is single-sourced and won't drift. But the merge recipe + coder construction are duplicated, and the version pin (1.6.0) is independent in each — those can drift.

The two obvious fixes are both wrong here: importing core's coder would force a runtime import of the 1929-line solana/index.ts into the CCT op layer (which today only type-imports core — that's the load-bearing separation), and pushing the read into core would fatten getTokenPoolConfig for every core user who never touches CCT.

A third option that honors both separation and DRY: extract the merge + coder into a small neutral leaf under solana/idl/ (e.g. token-pool-coder.ts) that depends only on @coral-xyz/anchor and the IDL data files — never on solana/index.ts or cct/**. Core and CCT both import it; each keeps its own result projection (core's 4-field view, CCT's 15-field view). The load-bearing types-splice comment lives once, in one place.

With more CCT read ops coming (registry state, chain config, rate limits), establishing the leaf now — at the first duplication — is cheaper than retrofitting it at the third. If it feels premature for this PR, the fallback is just adding the merge comment to both copies and aligning the version pin. Either way, worth a decision before the next read op duplicates the coder again.

I extracted the shared IDL merge and token-pool coder into solana/idl/token-pool-coder.ts. Solana CCT now imports it.

[apedrob]

Should we use parsePublicKey directly?

[mervin-link]

I kept validatePublicKey for validation-only paths. This keeps validate() methods readable, while call ops that need a PublicKey use parsePublicKey directly.