feat(scheduled-ops): Squads delegation family (sweep + recurring)

Background

Spec 5 PR-B. `sweep` and `recurring` are indefinite-horizon scheduled ops — the user is never going to be online at every trigger moment. Per the spec, the right primitive is wallet delegation: user grants a scope-limited authority to a server-controlled key (Squads Smart Account for first ship, custom `sipher_delegation` program later).

What to do (C.2 Squads-based)

1. New onboarding step for sweep/recurring — first invocation prompts user to:
   • Create a Squads Smart Account (or link existing)
   • Add sipher's operator pubkey as a spending member with caps tailored to the op
   • Approve via Squads UI
2. `scheduled_ops` execution — for `op_kind === 'delegated'`, COURIER:
   • Loads user's Smart Account + spending member config
   • Builds the stealth send tx
   • Server signs with sipher operator key
   • Broadcasts; Smart Account program enforces the spending limit
3. Operator key management — per-deployment operator keypair (mainnet, devnet), VPS secrets, rotation procedure documented

Why

• Only feasible mechanism for indefinite-horizon scheduled ops without 24/7 user availability
• Squads is production-tested + audited; no new on-chain program to maintain
• Smart Account spending limits enforce scope cryptographically

Trust posture

• Compromised sipher operator key → drains delegated wallets within spending caps
• Mitigation: HSM/KMS for prod, daily-rotating operators, out-of-scope tx alerts
• Privacy regression: Smart Account is a transparent on-chain entity, partial defeat of sipher's privacy goal — document as a feature trade-off

Cost

~3-4 weeks (one PR). Sub-tasks:

• Squads SDK integration
• Onboarding UX (Smart Account creation + spending member addition)
• Operator keypair generation + secret storage
• Spending-limit policy templates per sipher tool
• Feature flag: `SIPHER_DELEGATED_OPS_ENABLED=false`

Future migration

Custom `sipher_delegation` program (C.1) restores full privacy posture when justified — tracked as a separate future spec.

References

• Spec: `docs/superpowers/specs/2026-05-15-scheduled-op-broadcasts-design.md` (Family C.2 section, lines ~178-209)
• Predecessor: #281
• Squads docs: see `/solana-defi:squads` skill

Acceptance

• sweep on devnet works end-to-end: user authorizes via Smart Account → COURIER fires on incoming deposit → stealth send confirms
• Spending-limit over-attempt fails cleanly with `delegation_limit_exceeded` error
• Revocation via Squads → next COURIER tick fails with `delegation_revoked` reason → op transitions to `cancelled`
• Growth-hook fires per execution

Start with docs/superpowers/specs/2026-05-15-scheduled-op-broadcasts-design.md, especially the Family C.2 section, then review predecessor #281 and the scheduled_ops and COURIER entry points. Map the Squads onboarding, delegated execution, key management, and feature flag work before implementation. Done means the listed devnet, spending-limit, revocation, cancellation, and growth-hook acceptance cases pass.