Bump Codama renderers and regenerate clients

[lorisleiva]

This PR bumps @codama/renderers-js to 2.5.0 and @codama/renderers-rust to 3.1.3, regenerating both clients. The JS client adopts the wider instruction-account input types the new renderer emits, so signer and non-signer accounts now accept any address carrier, account meta, or program-derived address in addition to the previous inputs, while remaining backwards compatible with existing call sites. The Rust client picks up the corrected CPI remaining-accounts meta, whose is_signer/is_writable fields were previously mapped in the wrong order. The @solana/kit floor moves to ^8.3.0 to match, and four end-to-end tests on transferSol exercise the new JS inputs against LiteSVM.

[lorisleiva]

@trevor-cortex

[trevor-cortex]

Summary

Bumps @codama/renderers-js 2.3 → 2.5 and regenerates the 14 instruction builders. The regenerated code swaps the TAccountX extends string generics (with TransactionSigner<T> / Address<T> fields) for InstructionSignerInput / InstructionAccountInput constraints, threads the resolved metas through ResolvedInstructionAccountMeta<T, InstructionAccountInputAddress<T>> in the return type, adds isSigner to each originalAccounts entry, and hoists getAccountMetaFactory above the account resolution. @solana/kit peer + dev floor moves to ^8.3.0 (where those program-client-core types land), and four new LiteSVM tests on transferSol cover the widened inputs.

I diffed all 14 generated files — they're uniform renderer output with no hand-edits, and programs/system.ts was untouched (its plugin signatures use the non-generic XInput defaults, so they pick up the wide types for free).

Things to watch

• Peer floor bump is effectively breaking for consumers on kit 8.0–8.2. InstructionSignerInput & co. don't exist in program-client-core before 8.3, so the floor is correct and necessary — just make sure the release that ships this gets the appropriate bump for the repo's semver policy rather than a patch.
• Lockfile churn is bigger than the change. clients/js/pnpm-lock.yaml re-resolved a bunch of unrelated devDeps within range (oxlint → 1.83.0, vitest → 4.1.11, typedoc → 0.28.20, etc.). Nothing wrong with that, but it's why the diff is ±2k lines and it's worth confirming lint/format/tsc are green with the newer oxlint/oxfmt before merging.
• Tests only exercise the plugin path. All four new tests go through client.system.instructions.transferSol(...), whose parameter is the non-generic TransferSolInput (defaults to the wide unions). That validates runtime resolution of each input kind, but it doesn't touch the generic inference path of calling getTransferSolInstruction(...) directly — i.e. that ResolvedInstructionAccountMeta<TAccountDestination, ...> collapses to WritableAccount<Address<'…'>> for a PDA/HasAddress input. Optional follow-up: one expectTypeOf(getTransferSolInstruction({ source, destination: pda, amount }).accounts[1]).toEqualTypeOf<...>() style assertion would lock that in.

Notes for subsequent reviewers

Generated files can be verified with a fresh pnpm generate — should be a no-op against this branch. The interesting surface is clients/js/test/transferSol.test.ts and the two package.json bumps; a few small nits inline there.

[trevor-cortex]

Summary (re-review)

Since my last pass the PR grew a second axis: @codama/renderers-rust 3.1.0 → 3.1.3 and a regen of the 14 Rust instruction files. The JS side is unchanged from what I approved (same 14 generated files, same line counts), and the test file picked up the follow-ups I asked for. Still approving.

Rust change is a genuine bug fix. Every *Cpi::invoke_signed_with_remaining_accounts was building the remaining-account AccountMeta as is_signer: .1, is_writable: .2, while everything feeding those tuples — add_remaining_account(account, is_writable, is_signer), the add_remaining_accounts doc comment, and the __remaining_accounts: Vec<(AccountInfo, is_writable, is_signer)> field doc — uses (info, is_writable, is_signer). So any caller of the CPI builders who passed remaining accounts had their writable/signer flags swapped on the wire. The regen now maps .1 → is_writable, .2 → is_signer, consistent across all 14 files. I checked transfer_sol.rs in full to confirm the tuple order at the producer side; the other 13 diffs are byte-identical modulo the impl name.

Test follow-ups landed: the address-carrier test now asserts destination.address is not among the signatures, the PDA test uses SYSTEM_PROGRAM_ADDRESS, and there's a new expectTypeOf test pinning the generic inference through getTransferSolInstruction directly. One small note on the last one inline.

Things to watch

• Rust crate needs a release too. The CPI fix is a behaviour change for on-chain callers: anyone who noticed the swap and compensated by passing (info, is_signer, is_writable) will now get the opposite bug. That's the correct direction, but it deserves a patch bump + changelog line on the Rust client, separate from the JS release.
• Type-level assertions only bite if test files are type-checked. expectTypeOf is a runtime no-op; the assertions are enforced by tsc (or vitest's typecheck mode) covering test/**. Worth confirming clients/js tsconfig / the lint script includes the test directory — otherwise the new test is green regardless of what it asserts.
• Import ordering nit from last time (getProgramDerivedAddress before generateKeyPairSigner) is still there. If oxfmt/oxlint ran clean on this branch, ignore it — I don't want to fight the formatter.

Notes for subsequent reviewers

Both regens are pure renderer output and should reproduce with pnpm generate. The only hand-written surface remains clients/js/test/transferSol.test.ts and the two package.json bumps.