Require 2/3 or token holder supermajority for proposal launch

[metapileks]

What & why

Adds a stricter, per-DAO opt-in gate for launching proposals. A DAO that opts in (is_proposal_validation_enabled) launches only when one of two conditions holds:

• Approval points — at least 2 of 3: { stake ≥ base_to_stake, team-sponsored, MetaDAO-approved }.
• Supermajority — amount_staked alone reaching a per-DAO bar (dao.base_to_supermajority; 0 disables it).

DAOs that have not opted in keep today's gate unchanged (is_team_sponsored || amount_staked ≥ base_to_stake); the supermajority and MetaDAO signals are not consulted for them. Existing DAOs migrate in with validation off, so their behavior is unchanged until they opt in via update_dao. New launchpad-created DAOs default to on.

Changes

futarchy program

• New Dao.is_proposal_validation_enabled (set at creation, toggled via update_dao). launch_proposal branches on it: legacy gate when off, the two-condition gate when on.
• New approve_proposal instruction + Proposal.is_metadao_approved — the MetaDAO approval point. Approver is the MetaDAO multisig, gated under #[cfg(feature = "production")]. Rejected with ProposalValidationDisabled unless the DAO has is_proposal_validation_enabled — the approval point is inert under the legacy gate, so approving there is disallowed rather than written as dead state.
• New Dao.base_to_supermajority config with the invariant base_to_supermajority == 0 || >= base_to_stake, keeping the supermajority path never easier than the ordinary stake point.
• Two permissionless, idempotent realloc cranks to migrate in-flight accounts: resize_proposal (+1 byte: is_metadao_approved) and resize_dao (+9 bytes: base_to_supermajority + is_proposal_validation_enabled, both defaulted off).

Launchpads (v06/v07/v08) — pass is_proposal_validation_enabled: true and the supermajority default in InitializeDaoParams (internal CPI args; no surface change).

SDK (v0.6) — approveProposalIx; baseToSupermajority and isProposalValidationEnabled added to init/update params; resize_dao no longer takes a base_mint account; regenerated IDL types. launchProposalIx unchanged.

[github-actions]

Repository Guard

• Cargo.lock: pass
• yarn.lock (root): pass
• yarn.lock (sdk): pass
• Repo guard: pass

Repository Guard

Cargo dependency pinning

• Status: pass
• Every programs/*/Cargo.toml dep uses =x.y.z, a path = .. workspace ref, or a git dep with a 40-char rev.

Cross-program Anchor/Solana version consistency

• Status: pass
• anchor-lang and anchor-spl are pinned to the version declared in repo-guard.toml across every program.

solana-program crate pin

• Status: pass
• Every solana-program = "=X" declaration is =1.17.14 (locked to match Cargo.lock).

Anchor.toml solana_version

• Status: pass
• Anchor.toml declares solana_version = "1.17.34" (local-dev install for anchor test).

Crate minimum age

• Status: pass
• All Cargo deps changed by this PR are at least 14 days old on crates.io.

Yarn package.json pinning

• Status: pass
• All package.json deps use exact versions (no ^, ~, ranges).

npm minimum age

• Status: pass
• All npm deps changed by this PR are at least 14 days old.

Workflow toolchain consistency

• Status: pass
• Every workflow declares anchor-version: 0.29.0.
• Per-file solana-cli-version values match [toolchain.workflow_solana_cli] in repo-guard.toml.

GitHub Action SHA pinning

• Status: pass
• Every third-party action is pinned to a SHA in [actions.sha_allowlist].

Sensitive program / config changes

• Status: warn
• Review hint only (CODEOWNERS is the merge gate). Lines below match heuristics for security-sensitive changes:
• programs/futarchy/src/instructions/approve_proposal.rs:5 declare_id! literal change; Hardcoded Solana address literal -> + declare_id!("6awyHMshBGVjJ3ozdSJdyyDE1CTAXUwrpNMaRGMsb4sf");
• tests/futarchy/unit/updateDao.test.ts:136 Program ID constant or variable change -> + squadsMultisigProgram: multisig.PROGRAM_ID,

Overall status: pass

Lockfile freshness (Cargo.lock + yarn.lock) is checked by the workflow directly and cannot be bypassed. The sensitive-diff section is a review hint - CODEOWNERS handles the actual merge gate.