Keep shared Google Calendar events editable

[3mdistal]

Problem

When the same Google calendar is visible through both an owner account and a reader account, Calendar could keep whichever duplicate event arrived first. If the reader copy won, an event the user owns appeared read-only and its edit and delete actions disappeared.

Approach

Choose the strongest source for a duplicated provider event: writable access first, then primary ownership, access role, and a deterministic account fallback. Preserve account identity in multi-account event IDs so reads and mutations return to the connection that supplied the event.

What changed

• rank duplicate Google event sources by effective write access instead of arrival order
• use opaque account-scoped IDs for multi-account primary results, including explicitly selected source paths
• retain that binding in selected-source reads and get, update, RSVP, delete, and bulk mutation results; reject mismatched accounts and mixed scoped/legacy bulk requests
• surface Google provider and token-refresh failures on account-scoped reads instead of presenting them as event not found
• preserve and reopen read-only fallback events with their actual source/error provenance when a writable account fails
• add Calendar regression coverage and a user-facing changelog entry

CI guard repair

• scope the Slides design-system doc-count cache update to the resolved resource owner; the required unscoped-query guard exposed this pre-existing main issue during PR validation

Safety and operations

Existing single-account Google event IDs remain compatible. There are no schema, migration, or credential changes.

Verification

• nine affected Calendar suites: 216 tests passed after review fixes
• Calendar typecheck passed
• guard:no-silent-coercion, guard:external-result-contract, and git diff --check passed
• Slides get-design-system tests: 3 passed; Slides typecheck passed after building its workspace dependency
• desktop and 390x844 interface checks on the original implementation confirmed writable events expose edit/delete controls and reader-only events remain locked, with zero browser errors
• bounded technical review of the original implementation found no remaining issues; the later PR bot findings were repaired and covered by focused tests

The interface checks used the Calendar demo rather than a destructive mutation of a personal Google event. Provider routing and mutation rejection are covered at the action boundary.

Review focus

• source ranking when owner and reader connections expose the same provider event
• compatibility and parsing of account-scoped event identities
• account binding of mutation responses and bulk requests
• provider-error and read-only fallback provenance
• Slides doc-count update owner scoping

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[builder-io-integration]

Builder reviewed your changes — looks good ✅

Review Details

Incremental Code Review Summary

The latest commit fixes the previously open explicit bulk-delete result-ID issue by applying googleEventResultId, preserving opaque account-scoped IDs while restoring canonical google-<provider-id> output for legacy inputs. The added regression assertion covers the canonical IDs, and the broader Calendar source validation, account binding, fallback provenance, and Slides owner-scoped cache-write changes remain consistent. Three parallel incremental reviewers found no additional confirmed defects.

The prior comment was resolved after verifying the fix. No new actionable code-review findings are being posted in this cycle.

🧪 Browser testing: Could not verify — the dev server was healthy and HTTP routes returned successfully, but Chrome/browser automation tools were unavailable. All 14 planned Calendar/Slides cases were reported as environment-blocked.