Google Calendar Phase 2: redesign M7 as QR-link auth transfer

[h4yfans]

Summary

• redesign M7 so Google refresh tokens transfer only during trusted QR device linking, not through durable record sync
• add provider-auth payload support to the linking contracts, sync-server linking session, and desktop linking flow
• keep Google auth device-local outside linking, add reconnect-required status semantics, and sweep the related multi-account routing fixes
• update the Phase 2 spec to make the redesigned M7 source of truth explicit

Security Review Conclusion

The original M7 design was blocked: durable synced refresh-token blobs in calendar_sources and the normal encrypted sync pipeline were rejected.

Approved redesign: transfer Google refresh tokens only during trusted QR device linking through the existing short-lived encrypted linking session. Tokens remain device-local during normal operation, access tokens never leave the device, and stale devices recover via Reconnect Google instead of durable cross-device token sync.

Verification

• pnpm --dir apps/desktop exec vitest run --config config/vitest.config.ts src/main/calendar src/main/sync src/main/crypto src/renderer/src/components/calendar src/renderer/src/components/settings
• pnpm typecheck
• pnpm ipc:check
• pnpm lint (repo-wide warning-only baseline remains; touched Google files were checked clean)

Notes

• real Google / webhook E2E was not run locally in this branch
• spec updated: docs/superpowers/specs/2026-04-18-google-calendar-phase-2-design.md