feat(sdk-node): auto-airdrop configured addresses in the kit plugin

[amilz]

In attach mode the kit client must already carry a payer, and that signer is typically unfunded on the running Surfnet — so every caller had to make a separate cheatcode call before they could send anything.

surfpool() now takes airdropAddresses (bare addresses or anything carrying one, e.g. signers) plus an optional airdropAmount, funding each entry while the client is composed:

const client = await createClient()
  .use(payer(myPayer))
  .use(surfpool({ airdropAddresses: [myPayer], rpcUrl: "http://127.0.0.1:8899" }));

Decisions worth flagging:

• Funds via the setAccount cheatcode, not client.airdrop. The faucet path confirms over WebSocket, and the attach-mode WS URL is a derived guess (the port-8900 heuristic). Tying client construction to that heuristic being right is the wrong trade; the cheatcode needs HTTP only.
• Top-up semantics. An address already holding at least airdropAmount is skipped, and only the lamport balance is written, so existing data and owner survive. Idempotent, and never lowers a balance that a runbook already set.
• Default 10 SOL, matching Surfnet's own airdrop_lamports default.
• Failures throw, naming the address, with the RPC error as cause — silent under-funding would resurface later as a confusing transaction failure.
• Attach mode stays synchronous unless the option is present, so existing sync .use() callers keep working. The sync overload rejects a possibly-present airdropAddresses ({ airdropAddresses?: never }); without that, a conditional value would type as sync while dispatching async, handing back a Promise typed as a client.

Works in embedded mode too, alongside the pre-funded payer.

--

One thing that I have mixed feelings about @MicaiahReid ...

• an alternative approach might be to just prefund the client's payer client.payer.address. I think this would make sense but maybe could be annoying for folks that don't want it funded for some reason? idk.
• another thought is should this be more than just airdrop in the future...like mints/tokens/etc (almost like a mini runbook config?). if that's the case, may want to step back from this pr and do some thought on longer term design before shipping this. WDYT?

--

Closes TOO-650

[linear]

TOO-650

TOO-651

[greptile-apps]

Greptile Summary

The PR adds optional startup funding for configured addresses in embedded and attach modes.

• Adds bigint-safe amount validation and top-up behavior through the existing setAccount cheatcode.
• Adds synchronous and asynchronous attach-mode overloads, exports, documentation, type tests, unit tests, and an embedded smoke test.
• The commits must be signed and verified before merge.

Confidence Score: 4/5

The implementation appears functionally sound, but the unsigned commits must be replaced with signed, verified commits before merging.

The previously reported amount-validation failures are fixed, but every commit in the reviewed range lacks the verified signature required by the repository.

Important Files Changed

Filename	Overview
crates/sdk-node/surfpool-sdk/kit/surfpool.ts	Adds configurable address funding, validates unsafe and negative amounts, and preserves synchronous attach behavior when funding is absent.
crates/sdk-node/scripts/kit-unit.js	Covers funding targets, defaults, top-up skipping, amount validation, synchronous behavior, and RPC failures.
crates/sdk-node/scripts/kit-smoke.js	Verifies configured funding against a running embedded Surfnet.
crates/sdk-node/surfpool-sdk/kit/typetests/typetests.ts	Verifies attach-mode return types and rejects ambiguous optional funding configurations.
crates/sdk-node/README.md	Documents configured address funding, defaults, and top-up semantics.
crates/sdk-node/surfpool-sdk/kit/index.ts	Exports the new airdrop target and funded attach configuration types.

_{Reviews (3): Last reviewed commit: "fix(sdk-node): reject negative airdropAm..." | Re-trigger Greptile}