refactor(calendar): generalize the sync engine off Google (#1393)

[h4yfans]

Closes #1393. Phase 0 of the multi-provider calendar epic #1390.

Stacked on #1422 (#1392), which is stacked on #1407 (#1391). Base is h4yfans/calendar-provider-registry.

What

google/sync-service.ts held the whole engine in 917 lines. What bound it to Google was narrow and countable: a dozen provider: 'google' literals, a direct createGoogleCalendarClient() import, and a module-global syncInFlight boolean — one slot, shared by everything.

The engine moves to calendar/sync/ and takes a ProviderSyncContext (adapter factory, account routing, connection check, push toggle, default target calendar):

Was	Now
discoverGoogleCalendarSources	discoverProviderSources
syncGoogleCalendarNow	syncProviderNow
pushSourceToGoogleCalendar	pushSourceToProvider
deleteSourceFromGoogleCalendar	deleteSourceFromProvider
applyGoogleCalendarWriteback	applyProviderWriteback
applyGoogleCalendarDelete	applyProviderDelete
syncGoogleCalendarSource	syncProviderSource

Behavior rules, now enforced by the engine

• Writes are gated by capabilities.supportsWrite at the engine level, not left to adapter politeness. A read-only provider cannot reach calendar_bindings through push, through the local-change path, or through inbound sync — and it never provisions a memrynote calendar.
• incrementalMode drives cursor handling. Only sync-token / delta-link treat a missing cursor as invalidation. A conditional-get feed has no cursor to lose, so the reset branch cannot fire for it — otherwise every ICS poll would re-read from scratch forever.
• ProviderGoneError clears sync_cursor and re-runs the source. Google's plain status: 410 shape is still recognized, so today's behavior is bit-for-bit unchanged.
• syncInFlight is a per-provider set. One slow provider no longer blocks every other one.
• The runner is per-provider: its own timer, resume listener, trigger cooldown and cadence. PUSH_BACKOFF_INTERVAL_MS still applies to push-capable providers; supportsPush: false stays on the polling cadence. FOCUS_TRIGGER_COOLDOWN_MS and WINDOW_FOCUS_REASON behavior is preserved exactly.
• ProviderRateLimitError parks that provider until its own retryAfterMs elapses, without touching any other provider's schedule.
• push-conflict-retry.ts is kept and expresses the 412 case as ProviderConflictError + If-Match; Google's raw status: 412 still counts.

How the Google suite stayed untouched

Rather than rewrite the Google tests, Google is expressed as one bound context in providers/google/sync-service.ts that keeps every exported name and signature. google-sync-runner.ts does the same over the generic runner. mappers.ts moved to sync/remote-event-mappers.ts — it was always provider-neutral, it maps the shared remote-event shape — with a re-export left at the old path so mappers.test.ts did not even move.

Result: the entire existing Google calendar suite passes with zero edits — no assertion, no mock, no import path. That is the correctness proof the issue asked for.

engine.ts crossed the 800-line max-lines limit, so the inbound half (applyProviderWriteback / applyProviderDelete and their publishers) is split into sync/writeback.ts, the same way push-conflict-retry.ts was split out originally.

Verification

• pnpm typecheck — 16/16 green
• pnpm lint — 0 errors
• Desktop, per project: shared 2455 · main 6363 passed / 1 expected fail / 4 skipped (517 files) · main-integration 9 · renderer 6965 passed / 6 skipped

New sync/engine.test.ts (9 tests) and sync/runner.test.ts (6 tests) against an in-memory fake adapter, covering exactly the issue's checklist:

• two providers sync concurrently, neither blocks the other — and a second sweep of the same provider is still refused
• a supportsWrite: false adapter produces no calendar_bindings row under any path (direct push, local-change path, inbound sync), and no memrynote calendar
• ProviderGoneError resets the cursor and re-runs with syncCursor: null
• a missing cursor resets a sync-token provider but is normal for conditional-get
• ProviderRateLimitError makes the runner wait retryAfterMs, skipping periodic polls inside the window and resuming after it, without throttling any other provider
• one timer per provider; stopping one leaves the other running

One pre-existing test changed: inbox/sync-enqueue-guard.test.ts is a tripwire listing every module that writes inbox triage state, and the inbox_snooze writeback moved from calendar/providers/google/sync-service.ts to calendar/sync/writeback.ts. The guard caught the move — exactly its job — so its expected path was updated. No assertion logic changed.

Docs

MEMRY_DOCS_IMPACT_SKIP=1 on push: no user-facing change. Google is still the only provider, the cadence and cooldowns are identical, and no setting, schema or channel moved. Docs land with #1394 and #1396.

[github-actions]

React Doctor found no new issues. 🎉

_{Reviewed by React Doctor for commit ec745e7.}

[codecov]

Codecov Report

❌ Patch coverage is 91.86228% with 52 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
apps/desktop/src/main/calendar/sync/engine.ts	91.32%	23 Missing ⚠️
apps/desktop/src/main/calendar/sync/runner.ts	91.45%	10 Missing ⚠️
...top/src/main/calendar/sync/remote-event-mappers.ts	91.26%	9 Missing ⚠️
...in/calendar/providers/google/google-sync-runner.ts	72.72%	6 Missing ⚠️
apps/desktop/src/main/calendar/sync/writeback.ts	98.01%	2 Missing ⚠️
...src/main/calendar/providers/google/sync-service.ts	94.11%	1 Missing ⚠️
...ktop/src/main/calendar/sync/push-conflict-retry.ts	91.66%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!