feat: migrate governance positions + getPositions, harden fee-payer rent accounting

[bryzettler]

Summary

Extends /migrate to migrate VSR governance positions (vehnt/veiot/vemobile) alongside tokens and hotspots, adds governance.getPositions for the wallet UI, and hardens fee-payer rent accounting. Positions are discovered server-side (registrar-agnostic, no new input) and transferred with transferPositionV0. Migration stays rent-neutral: the fee payer fronts destination-ATA rent and recovers it by closing the source ATA.

Changes

• feat: migrate governance positions — enumerate every VSR position the source owns (freeze-authority classification) and transfer each to the destination; re-enumerated per paginated call, so migrated positions drop out naturally.
• feat: governance.getPositions — GET /governance/positions/wallet/{wallet} returns mint, position, registrar, amountDeposited (TokenAmountOutput shape), numActiveVotes, lockup.
• fix: skip stale-enumerated positions — verify the source ATA still holds the NFT before building each transfer; avoids TransferPositionV0 → AccountNotInitialized (3012) when a lagged RPC index reports a closed ATA.
• fix: group create/close instructions — token ([createAta, transfer, close]) and position ([transferPositionV0, close]) are built as grouped TransactionInstruction[][] so each pair stays in one tx. Closes a rent-drain where a flat list could split a fee-payer-funded create from its offsetting close, letting a caller land the create alone and strand the rent. Enforced at build layer, independent of client submission. Mirrors the split-hotspot pattern.

Testing

• migration.test.ts: 10/10 (incl. VSR position migration).
• governance.test.ts: 33/33 (incl. getPositions amountDeposited assertions).

Security review — known & accepted (both pre-existing, /migrate is public so client trust isn't a safeguard)

1. Mini-fanout subsidy (~0.01 SOL) — intended cost of recreating the reward-split config at the destination; bounded by existing rate limiting. No fix that doesn't break legitimate fanout migrations.
2. Isolated Jito tip (~10k lamports) — after the grouping fix, the only remaining strandable cost, in the same bucket as the irreducible base tx fee. Rate limiting is the right control; a full server-side atomic-submission architecture would only shave the tip, not base fees. Revisit if a new non-self-neutralizing fee-payer-funded instruction is added.

[madninja]

Reviewed the substantive changes (the grouping/atomicity fix, VSR position migration, getPositions, and the rate-limiter swap). Core mechanics are correct: I verified the batcher pushes each group all-or-nothing (slice(0, prevLen) rollback), and transferPositionV0 creates the dest ATA on the fee payer + leaves PositionV0/numActiveVotes untouched, so the paired close keeps it rent-neutral and mid-vote positions migrate fine.

Leaving inline notes, ranked. #1 is the only one that can hard-fail a real user with no workaround; the rest are cleanup/perf/hardening. The accepted-risk section is fair on the on-chain economics — the main caveat is that the rate limiter isn't an abuse boundary (keys are caller-controlled) and the unbounded surface is server RPC cost, not fee-payer drain.