test(asm): upgrade to litesvm 0.13.1, patch solana-kite, unpin sbpf

Verify end-to-end whether litesvm 0.13.1 (Agave 4.0) loads sbpf's SBPF v3
output, so the sbpf revision pin can be removed.

- Workspace litesvm 0.11.0 -> 0.13.1
- [patch.crates-io] points solana-kite at the litesvm-0.13 branch, which
  relaxes solana-instruction to >=3.2 so it can coexist with litesvm 0.13.1's
  =3.2.0 pin (the 0.3.0 crates.io release requires ^3.3.0 and blocks the
  upgrade). solana-kite reaches the root workspace via finance/vault-strategy.
- checking-accounts/asm and create-account/asm now inherit litesvm from the
  workspace, so all four asm crates build against 0.13.1
- Drop the sbpf --rev pin so sbpf HEAD emits SBPF v3; this run is the test

If CI is green, litesvm 0.13.1 loads SBPF v3 and the pin can go permanently.
If it fails on InvalidAccountData, 0.13.1's default feature set does not
enable SBPF v3 execution and the pin (or an explicit FeatureSet) is still
needed.

Author: Claude

.github/workflows/solana-asm.yml

@@ -199,17 +199,11 @@ jobs:
           # Make the script executable
           chmod +x build_and_test.sh
 
-          # Install sbpf assembler.
-          #
-          # Pin to a specific revision: installing from the branch HEAD makes the
-          # build non-reproducible and breaks CI whenever sbpf changes its output.
-          # On 2026-06-29 sbpf merged its SBPF v3 work (PR #127), switching the
-          # emitted ELF to the v3 / 0x03 OS-ABI format. litesvm 0.11.0's loader
-          # rejects that format, so every asm test started failing at
-          # `svm.add_program(...).unwrap()` with Instruction(InvalidAccountData).
-          # This rev is the last commit before the v3 changes and matches the
-          # toolchain from the last green run; bump it together with litesvm.
-          cargo install --git https://github.com/blueshift-gg/sbpf.git --rev 0223df0e7ba622d4956b4ecf3cf2397f6945b76b
+          # Install sbpf assembler from HEAD. HEAD emits SBPF v3 (0x03 OS-ABI)
+          # ELF, which requires litesvm >= 0.13 (Agave 4.0) to load; the
+          # workspace pins litesvm 0.13.1. If a future sbpf change breaks
+          # loading, pin a revision here with --rev.
+          cargo install --git https://github.com/blueshift-gg/sbpf.git
       - name: Setup Solana Stable
         uses: heyAyushh/setup-solana@v5.9
         with:

Cargo.toml

@@ -98,10 +98,17 @@ pinocchio-system = "0.5.0"
 pinocchio-pubkey = "0.3.0"
 
 # testing
-litesvm = "0.11.0"
+litesvm = "0.13.1"
 solana-instruction = "3.0.0"
 solana-keypair = "3.0.1"
 solana-pubkey = "3.0.0"
 solana-transaction = "3.0.1"
 solana-native-token = "3.0.0"
 solana-address = "2.6.0"
+
+# Patch solana-kite to a branch that supports litesvm 0.13.x while this is
+# validated in CI. solana-kite 0.3.0 on crates.io requires solana-instruction
+# ^3.3.0, which cannot coexist with litesvm 0.13.1's pin of =3.2.0; the branch
+# relaxes that to >=3.2. Replace with a published version once released.
+[patch.crates-io]
+solana-kite = { git = "https://github.com/solanakite/kite-rust", branch = "litesvm-0.13" }

basics/checking-accounts/asm/Cargo.toml

@@ -6,7 +6,7 @@ edition = "2021"
 [dependencies]
 
 [dev-dependencies]
-litesvm = "0.11.0"
+litesvm.workspace = true
 solana-instruction = "3.0.0"
 solana-keypair = "3.0.1"
 solana-native-token = "3.0.0"

basics/create-account/asm/Cargo.toml

@@ -6,7 +6,7 @@ edition = "2021"
 [dependencies]
 
 [dev-dependencies]
-litesvm = "0.11.0"
+litesvm.workspace = true
 solana-instruction = "3.0.0"
 solana-keypair = "3.0.1"
 solana-native-token = "3.0.0"