[mosskappa]

Summary

Addresses #62: avoid a repeated SAS emoji confirmation when a server response still advertises the already-used sas.confirm action.

Changes

• Track locally confirmed verification IDs; never send sas.confirm twice for the same ID in one CLI run.
• Refresh setup state after a stale reply and return pending (rather than falsely claiming success) if the other device has not finished.
• Treat only a raced HTTP 409 with verification_action_not_available and details.state: "done" as a completed action, then re-read readiness. Other 409s still fail normally.
• Stop driving verification after the app advances to needs-first-sync or ready, instead of creating a new verification request.
• Show an actionable waiting-state message on stderr for human mode without corrupting JSON output.

Validation

• bun run --cwd packages/cli build — passed.
• bun run --cwd packages/cli typecheck — passed.
• bun test packages/cli/test/*.test.ts — 53 passed, 0 failed.
• Five new local fake-server regression cases covering stale confirmation, still-pending state, completed-race 409, unrelated 409, and first-run request.

The tests contain synthetic data only; no account tokens, keys, or private messages.

Scope

This is a CLI-only fix, without indefinite polling. PR #66 separately repairs the SDK resource names and may need to land first.