feat(blockchain-api): Squads v3 proposal lifecycle endpoints

[madninja]

Adds a standalone squadsV3 router giving Squads v3 multisigs the same proposal-lifecycle surface the v4 router already provides, under /squads/v3/*. Built on @sqds/sdk.

Endpoints

Endpoint	Path
approveProposal	POST /squads/v3/proposals/approve
rejectProposal	POST /squads/v3/proposals/reject
cancelProposal	POST /squads/v3/proposals/cancel
executeProposal	POST /squads/v3/proposals/execute
proposeConfigChange	POST /squads/v3/proposals/config

Each returns unsigned transaction(s) for the acting member to sign, matching the v4 response envelope.

Notes on the v3 model

• v3 votes/execute key off the transaction PDA directly (no separate proposal account as in v4), so inputs are { member, multisig, transactionPda }.
• proposeConfigChange builds createTransaction + addInstruction + activateTransaction into one unsigned tx, mirroring v4's create-only (no auto-vote).
• The version-neutral buildSquadsTransaction (+ types) is factored into lib/utils/squads-tx.ts and shared by both routers; v4 re-exports it, so v4 consumers are untouched.

Draft — one item needs verification before merge

See the flagged inline comment: the authorityIndex for v3 config-change transactions is set to 0 and has not been verified end-to-end against the on-chain squads-mpl program. The four vote/execute endpoints have unambiguous account derivation; only proposeConfigChange carries this open question.

[madninja]

⚠️ Needs on-chain verification before this endpoint ships.

CONFIG_AUTHORITY_INDEX = 0 is my best reading of Squads v3 (index 0 = the multisig's internal/config authority; index 1 = default vault), but the actual signer for addMember/removeMember/changeThreshold self-CPIs is decided by the on-chain squads-mpl Rust program, which isn't in node_modules. I could not verify it end-to-end from here.

If the index is wrong, proposeConfigChange will build and activate fine but the proposal will fail at execute time (invalid signer). Please confirm against a real v3 multisig on devnet — run an add/remove/threshold proposal through create → approve → execute — before this endpoint is trusted. The four vote/execute endpoints don't depend on this.

[madninja]

Closing as not planned. There is no current need for v3 proposal lifecycle support, so this
should not sit open collecting stale CI.

State at close, for anyone picking it up:

• The four vote/execute endpoints (approve, reject, cancel, execute) have unambiguous account
  derivation and were the straightforward half.
• proposeConfigChange was never verified. Its authorityIndex is hardcoded to 0 and was
  not checked end to end against the on-chain squads-mpl program. Treat that as unknown, not
  as a default worth trusting.
• buildSquadsTransaction and its types were factored out to lib/utils/squads-tx.ts and
  shared by both routers, with v4 re-exporting them. That refactor is independent of v3 and
  is the one piece worth salvaging on its own.

The branch feat/squads-v3 stays on the remote so this can be reopened. CI is red here only
because the base has moved since July; it is not a signal about the code.