test(tokens/hackathon): add Squads 2-of-3 LiteSVM Rust tests

Integration tests build a real Squads v4 multisig (Alice/Bob/Carol,
threshold 2-of-3) inside LiteSVM and drive the hackathon program end-to-end
through the propose / vote / execute flow.

Coverage (9 tests total):
- happy path: create_hackathon -> add_prize -> fund -> set_winner (via
  multisig vote) -> pay_winner (signed by an unrelated bystander wallet).
  Asserts the winner's token balance equals prize.amount.
- pay_winner failure cases: no winner set, vault under-funded, already
  paid.
- set_winner failure case: non-multisig signer rejected by Anchor's
  has_one = authority constraint.
- cancel_prize: drains a funded vault to a refund target, closes the
  vault, locks the prize against future pay_winner.
- close_hackathon: succeeds once every prize is paid or cancelled; fails
  while any prize is still active.

Implementation notes:

- Squads onchain program is vendored as a 1.5 MB .so fixture dumped from
  mainnet (SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf). The README has
  the refresh command.
- The Squads SDK crates (squads-multisig, squads-multisig-program) pull
  in solana-client 1.17, which conflicts with the Anchor 1.0 / Solana 3.x
  stack on zeroize. Instead, instruction builders are hand-rolled in
  tests/common/squads.rs: Anchor 8-byte discriminators (sha256("global:
  <name>")[..8]), Borsh args, plus the SmallVec<u8, T> wire format used
  by the compiled-message TransactionMessage struct.
- The Squads ProgramConfig account (which would normally be initialised
  by a Squads admin instruction we cannot run) is forged directly into
  LiteSVM via set_account with multisig_creation_fee = 0.

Also adds the README and bumps Cargo.toml with the sha2 dev-dependency
used by the Squads helper module.

Author: Edward (Edwardbot)

tokens/hackathon/anchor/README.md

@@ -0,0 +1,137 @@
+# Anchor Hackathon Prize Program (Squads multisig committee)
+
+A small Anchor 1.0 program for running a hackathon where a Squads multisig
+committee controls prize creation and award decisions, but anyone can trigger
+the actual onchain payment once a winner is recorded.
+
+## Why it exists
+
+Real hackathon organisers want:
+
+1. **A committee, not a single key.** No one person can quietly mint a
+   prize, change the winner, or run off with the funds.
+2. **Public, auditable awards.** Once the committee has voted "Alice wins
+   prize #3", anyone can execute the payout — the committee doesn't have to
+   stay online to hit a button.
+3. **Surplus reclaim.** If a prize is funded but never claimed, the
+   committee can refund it.
+
+This program does the onchain half. Squads handles the offchain voting and
+PDA-signing flow.
+
+## How the multisig integration works
+
+The program is multisig-agnostic. Each `Hackathon` account stores a single
+`authority: Pubkey`, and every privileged instruction handler checks
+`signer == authority`. In practice that pubkey is a Squads vault PDA: the
+committee proposes a vault transaction, votes on it, and when the threshold
+is reached the Squads program signs the inner instruction with the vault's
+PDA. Our program just sees a signed CPI from the vault and proceeds.
+
+This means:
+
+- You can swap Squads for any other multisig (Realms, Mean, a custom one)
+  without touching this program.
+- The program doesn't need to know multisig threshold, member set, or
+  voting state.
+- The program stays under 350 KB of compiled BPF.
+
+## Accounts
+
+```text
+Hackathon
+  authority      : Pubkey       // Squads vault PDA
+  name           : String       // human-readable; hashed into seeds
+  prize_count    : u8           // monotonic counter for Prize PDA seeding
+  bump           : u8
+  seeds = ["hackathon", authority, sha256(name)]
+
+Prize
+  hackathon : Pubkey
+  index     : u8                // stable assignment from prize_count
+  mint      : Pubkey            // one mint per prize
+  amount    : u64               // exact payout amount
+  winner    : Option<Pubkey>
+  paid      : bool
+  cancelled : bool
+  bump      : u8
+  seeds = ["prize", hackathon, index]
+
+Vault   = ATA(prize, mint)      // Prize PDA owns its own vault
+```
+
+Per-prize mints let one hackathon mix denominations (USDC for cash
+prizes, governance tokens for runner-up awards). Storing the prize index
+in the PDA seed avoids reallocating the `Hackathon` account every time a
+prize is added.
+
+## Instruction handlers
+
+| Handler            | Signer           | Behaviour                                                              |
+| ------------------ | ---------------- | ---------------------------------------------------------------------- |
+| `create_hackathon` | Multisig         | Initialise `Hackathon` under `authority`.                              |
+| `add_prize`        | Multisig         | Register a `Prize` with its own mint and a new vault ATA.              |
+| `set_winner`       | Multisig         | Record the winner pubkey for a prize.                                  |
+| `pay_winner`       | **Anyone**       | Transfer exactly `prize.amount` to the winner's token account.         |
+| `cancel_prize`     | Multisig         | Drain the vault to a refund target and lock the prize against payout. |
+| `close_hackathon`  | Multisig         | Refund `Hackathon` rent once every prize is paid or cancelled.        |
+
+`pay_winner` being permissionless is deliberate. Once the committee has
+voted, anyone — the winner, a bot, an organiser's intern — can submit the
+transaction. The committee doesn't need to stay online to deliver prizes.
+
+## Token model
+
+SPL Token Interface throughout (`InterfaceAccount<Mint>`,
+`InterfaceAccount<TokenAccount>`, `Interface<TokenInterface>`,
+`transfer_checked` from `anchor_spl::token_interface`). The same compiled
+program works for both classic SPL Token and Token-2022 mints; the choice
+is made per prize, at `add_prize` time, by passing the relevant mint.
+
+## Tests
+
+LiteSVM-based Rust integration tests build a real Squads v4 multisig
+(Alice / Bob / Carol, threshold 2-of-3) and drive the program end-to-end
+through Squads' propose / vote / execute flow.
+
+The Squads onchain program is loaded from a `.so` fixture at
+`programs/hackathon/tests/fixtures/squads_multisig.so`. To refresh it from
+mainnet:
+
+```
+solana program dump --url mainnet-beta \
+  SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf \
+  programs/hackathon/tests/fixtures/squads_multisig.so
+```
+
+Squads instructions (`multisig_create_v2`, `vault_transaction_create`,
+`proposal_create`, `proposal_approve`, `vault_transaction_execute`) are
+built by hand in `tests/common/squads.rs`. We don't depend on the
+`squads-multisig` SDK crate because it pulls in `solana-client 1.17`,
+which conflicts with our Anchor 1.0 / Solana 3.x stack.
+
+The Squads `ProgramConfig` account (normally written by a Squads admin
+instruction) is forged directly into LiteSVM with
+`multisig_creation_fee = 0`, so test setup is one synchronous call.
+
+### Coverage
+
+- **Happy path**: create → add_prize → fund → set_winner (via multisig
+  vote) → pay_winner (unpermissioned). Verifies the winner's token
+  balance equals `prize.amount`.
+- **Failure cases**: `pay_winner` rejects when no winner is set, when the
+  vault is under-funded, and when the prize has already been paid.
+  `set_winner` rejects a non-multisig signer.
+- **Lifecycle**: `cancel_prize` drains a funded vault to a refund target
+  and locks the prize. `close_hackathon` succeeds once every prize is
+  resolved and fails while any prize is still active.
+
+## Usage
+
+```
+cargo build-sbf
+cargo test
+```
+
+`cargo build-sbf` must run first because the integration tests load the
+compiled `.so` via `include_bytes!`.

tokens/hackathon/anchor/programs/hackathon/Cargo.toml

@@ -28,8 +28,10 @@ sha2 = { version = "0.10", default-features = false }
 litesvm = "0.11.0"
 solana-signer = "3.0.0"
 solana-keypair = "3.0.1"
+solana-account = "3.0.0"
 solana-kite = "0.3.0"
 borsh = "1.6.1"
+sha2 = "0.10"
 
 [lints.rust]
 unexpected_cfgs = { level = "warn", check-cfg = ['cfg(target_os, values("solana"))'] }

tokens/hackathon/anchor/programs/hackathon/tests/common/mod.rs

@@ -0,0 +1,11 @@
+// Test-side helpers. Split into modules so each file has a single
+// responsibility and the test files stay focused on behaviour, not plumbing.
+//
+// Each integration test compiles `common/` into a separate binary, so an
+// item used by one test binary but not another shows up as `dead_code`. The
+// allow attribute below silences those false positives across the whole
+// helper surface; real dead code is still caught by `cargo clippy`.
+#![allow(dead_code)]
+
+pub mod squads;
+pub mod world;