feat(calendar): Phase 2 M6 — multi-account Google + sync health UI

[h4yfans]

Summary

M6 of the Google Calendar Phase 2 plan. Closes the last two open gaps from the audit:

• G9 (single-Google-account-only) — Memry now supports an arbitrary number of connected Google accounts on the same device, each with its own keychain slot, source rows, and push routing.
• G10 (no sync health surface in UI) — Settings → Calendar shows per-account chips with status + last-error, and per-source rows with a status badge + Retry button.

Each commit follows TDD (RED → GREEN) and is independently green; final architecture refactor extracted push-conflict-retry to keep sync-service.ts under the 800-line eslint cap.

Commit-by-commit

#	Commit	Closes
T1	41ce2840 partition keytar entries by accountId	foundation for G9
T2	b33960b8 OAuth uses profile email as accountId	G9 connect flow
T3	1a4fef03 provider status IPC returns per-account array	G10 IPC surface
T4	8a3a6935 route push by target calendar's account	G9 outbound
T5	56454c07 scope DISCONNECT to a single account	G9 disconnect
T6	6db947d8 sync-health surface + lastError column + retry IPC	G10 renderer
T7	b607d079 extract push-conflict-retry from sync-service	refactor

(Plus 8150e4f4 chore: absorb prettier reformats from prior session)

Architecture highlights

• Per-account keychain partitioning: keytar account names are now <kind>-<accountId>[-<MEMRY_DEVICE>] so two Google accounts coexist without overwriting tokens. The new LEGACY_DEFAULT_ACCOUNT_ID constant landed in T1 as a transitional shim and was removed in T2 once userinfo became the canonical source of accountId.
• Userinfo as the source of truth: connectGoogleCalendar() calls oauth2/v2/userinfo immediately after token exchange. The returned email becomes both the keychain partition and the calendar_sources.accountId. Connecting a second account creates a second source row instead of overwriting the first.
• Per-account routing: new resolveTargetGoogleAccountId(db, target, existingBinding) walks (binding → event.targetCalendarId → default account) to determine which account's client to construct for each push. getGoogleClient accepts an optional accountId override so the routing decision flows all the way to keychain.
• Scoped disconnect: DISCONNECT_PROVIDER accepts an optional accountId. With it set, only that account's keychain is wiped, only its source rows are tombstoned (archivedAt), and only its push channels are torn down. Other accounts stay live. Without it, the legacy nuke-all path is preserved for the existing big "Disconnect" button.
• Sync-health surface: every sync error writes syncStatus='error' + a 200-char-truncated lastError to a new column (migration 0028). The renderer shows a status dot per calendar source and a "Retry now" button when status is error; clicking it invokes syncGoogleCalendarSource(id) via the new RETRY_GOOGLE_CALENDAR_SOURCE_SYNC IPC.
• Per-account chips: provider status now returns accounts: CalendarProviderAccountStatus[] so the renderer can render one chip per connected account with email + status + lastError.

Test plan

• pnpm --filter @memry/desktop exec vitest run src/main/calendar src/main/sync src/main/ipc src/renderer/src/components/calendar src/renderer/src/components/settings — 1149/1149 passing (108 files)
• pnpm --filter @memry/desktop typecheck:node && pnpm --filter @memry/desktop typecheck:web — both clean
• pnpm lint — 0 errors (912 pre-existing warnings carry over)
• pnpm ipc:check — generated bindings up-to-date
• Migration 0028 (calendar_sources.last_error TEXT) verified by 1149 vitest runs through createTestDataDb's in-memory migrate() pass — every test that INSERTs into calendar_sources exercises the migration
• Manual smoke before merge: connect first Google account, connect a second one with a different email, confirm both appear as chips and both calendars sync. Trigger an error (revoke token from Google), confirm chip flips to red + Retry button restores green.
• E2E (Phase 2 has no E2E for OAuth flow yet — defer to follow-up; current Playwright tests don't exercise OAuth)

Out of scope (follow-ups)

• Dedicated calendar_sync_status_changed projection event — current CHANGED event with entityType: 'calendar_source' already triggers TanStack invalidation, so the renderer refetches on every status change.
• Calendar-header status chip (the design's "small status chip in calendar header") — settings panel surface lands in this PR; header chip is a follow-up.
• Per-account disconnect button in the renderer — IPC supports it (accountId arg), but UI affordance is a follow-up; current behavior keeps the big provider-wide "Disconnect" button.

Known gotchas

• pnpm db:generate is not used (project gotcha, hand-write migrations since 0020). 0028 is hand-written + journal entry added manually.
• sync-service.ts post-T6 crossed the 800-line eslint cap; T7 extracts push-conflict-retry.ts to bring it back under (760 lines).

[h4yfans]

Code review

Found 4 issues:

1. Inbound poll uses one default-account client for every calendar — when account B is connected, its calendars get polled with account A's tokens and 401 (the routing fix in T4 only covered the outbound push path).

memry/apps/desktop/src/main/calendar/google/sync-service.ts

Lines 756 to 772 in b607d07

	syncInFlight = true
	try {
	const client = getGoogleClient(db, deps)
	await ensureMemryCalendarSource(db, client)
	const sources = listCalendarSources(db, {
	provider: 'google',
	kind: 'calendar',
	selectedOnly: true
	}).filter((source) => !source.isMemryManaged)
	for (const source of sources) {
	await syncGoogleCalendarSource(db, source.id, { client })
	}
	} finally {
	syncInFlight = false

2. ensureMemryCalendarSource and ensureGoogleCalendarSourceSelected blindly pick listCalendarSources(...)[0] to populate accountId on a newly-created calendar source row. With two accounts connected, the source can land with the wrong owner — and findAccountIdForCalendarRemoteId will then route subsequent pushes through the wrong tokens.

memry/apps/desktop/src/main/calendar/google/sync-service.ts

Lines 134 to 145 in b607d07

	const localId = `google-calendar:${remote.id}`
	const now = getNow()
	const account = listCalendarSources(db, { provider: 'google', kind: 'account' })[0]
	const existingSource = getCalendarSourceById(db, localId)
	const existed = Boolean(existingSource)
	const saved = upsertCalendarSource(db, {
	id: localId,
	provider: 'google',
	kind: 'calendar',
	accountId: account?.id ?? null,

memry/apps/desktop/src/main/calendar/google/sync-service.ts

Lines 209 to 220 in b607d07

	return null
	}
	const account = listCalendarSources(db, { provider: 'google', kind: 'account' })[0]
	const localId = `google-calendar:${remote.id}`
	const existingById = getCalendarSourceById(db, localId)
	const existed = Boolean(existingById)
	const saved = upsertCalendarSource(db, {
	id: localId,
	provider: 'google',
	kind: 'calendar',

3. buildProductionChannelManager resolves the default accountId once at construction and binds it to the channel manager for the runtime's lifetime. Second-account calendars never get push channels (silent fallback to polling); if the default account is later disconnected, every channel op fails with 401.

memry/apps/desktop/src/main/calendar/google/push-runtime.ts

Lines 86 to 97 in b607d07

	onActiveCountChange: (count: number) => void
	): GoogleChannelManager {
	const hmacKey = resolveHmacKey()
	const accountId = resolveDefaultGoogleAccountId(requireDatabase())
	if (!accountId) {
	throw new Error('Cannot start Google push channel manager without a connected account')
	}
	return createGoogleChannelManager({
	client: createGoogleCalendarClient({ accountId }),
	registerOnServer: async (body) => {
	const token = await getValidAccessToken()

4. New "Retry now" button uses onClick with disabled={isRetrying} — the exact anti-pattern the CLAUDE.md gotcha warns about ("Submit buttons that disable themselves mid-click lose the click. Fire submit from `onPointerDown`..."). The unit test had to switch from user.click to fireEvent.click to land — strong signal the gotcha actually fires. See calendar-quick-create-dialog.tsx for the canonical `onPointerDown` + `onClick` keyboard-fallback pattern.

memry/apps/desktop/src/renderer/src/components/settings/google-calendar-source-picker.tsx

Lines 86 to 98 in b607d07

	<Button
	variant="outline"
	size="sm"
	className="h-6 px-2 text-[10px]/3"
	disabled={isRetrying}
	onClick={() => onRetrySource(source.id)}
	data-testid={`calendar-source-retry-${source.id}`}
	>
	{isRetrying ? 'Retrying…' : 'Retry now'}
	</Button>
	)}
	<Checkbox
	id={inputId}

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}