feat(cct-sdk): Add get token admin registry config solana op

[mervin-link]

What

• DAPP-10787
• Add Solana CCT getTokenAdminRegistryConfig query operation
• Decode TokenAdminRegistry administrator, pending administrator, lookup table, and writable indexes
• Share TokenAdminRegistry account decoding with SolanaChain.getRegistryTokenConfig

Why

• Provide CCT SDK consumers a typed read API for inspecting Solana TokenAdminRegistry configuration

[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]

Solid, correct work with excellent fundamentals: the leaf is a clean pure decoder, the cross-family type was left untouched (the decisive non-breaking requirement), and the writableIndexes bitmap — the one part most likely to be wrong — is canonically exact and I confirmed it byte-for-byte against a live devnet account. npm run check is green and the op's tests pass.

Pre-merge asks (3): (1) fix the naming collision — and per the cross-family finding (comment ⑩) the fix should adopt a shared-base result shape (reuse core's RegistryTokenConfig triple with lookupTable?/writableIndexes/supportsAutoDerivation? additive), not just a rename, so EVM and Solana expose the same interface; (2) decide supportsAutoDerivation/mint (build or de-scope in the ticket); (3) the DRY / decoupling items are follow-up polish. The cross-family axis (comment ⑩, Major) elevates the naming + field-shape asks from polish to a DevX-bar item.

One process note: the design's byte-for-byte guardrail test on the getRegistryTokenConfig migration (comment ⑤) is missing — that migration silently changed a hot-path method's failure mode, and only the new op is covered.

Gates: npm run check -w ccip-sdk → green (lint+typecheck; 2 autofixable warnings). Op unit tests → 3/3 pass. npm ci → FAILS (lockfile out of sync: missing @emnapi/core@1.11.2); npm install works — pre-existing on the base.

[mervin-link]

Solid, correct work with excellent fundamentals: the leaf is a clean pure decoder, the cross-family type was left untouched (the decisive non-breaking requirement), and the writableIndexes bitmap — the one part most likely to be wrong — is canonically exact and I confirmed it byte-for-byte against a live devnet account. npm run check is green and the op's tests pass.

Pre-merge asks (3): (1) fix the naming collision — and per the cross-family finding (comment ⑩) the fix should adopt a shared-base result shape (reuse core's RegistryTokenConfig triple with lookupTable?/writableIndexes/supportsAutoDerivation? additive), not just a rename, so EVM and Solana expose the same interface; (2) decide supportsAutoDerivation/mint (build or de-scope in the ticket); (3) the DRY / decoupling items are follow-up polish. The cross-family axis (comment ⑩, Major) elevates the naming + field-shape asks from polish to a DevX-bar item.

One process note: the design's byte-for-byte guardrail test on the getRegistryTokenConfig migration (comment ⑤) is missing — that migration silently changed a hot-path method's failure mode, and only the new op is covered.

Gates: npm run check -w ccip-sdk → green (lint+typecheck; 2 autofixable warnings). Op unit tests → 3/3 pass. npm ci → FAILS (lockfile out of sync: missing @emnapi/core@1.11.2); npm install works — pre-existing on the base.

Addressed the pre-merge asks. The op is now getTokenAdminRegistry with RegistryTokenConfig base plus Solana fields. The reported npm ci lockfile issue will be address in other PR.