fix(web): redirect Google auth through callback

[Uarmagan]

Summary

This PR changes Google authorization in Compass from a popup-based flow to a full-page redirect flow. Both Google sign-in/sign-up and “Connect Google Calendar” now leave Compass through Google and return through a dedicated callback page at /auth/google/callback.

The PR also fixes a related local-data issue: seeded demo events are now marked as demo-only in the browser, so they do not get uploaded into a user’s real account when the user later signs in or connects Google.

Why This Changed

The previous Google flow relied on popup behavior and a looser redirect setup. That made the flow harder to reason about and left Compass depending on popup-specific cancellation/error handling.

This branch makes the Google flow explicit:

• Compass records why the user is going to Google before redirecting.
• Google sends the user back to a dedicated Compass callback page.
• The callback finishes the saved action: either Google sign-in/sign-up or connecting Google Calendar.
• The user is returned to the page they started from when it is safe to do so.

What Changed

Google authorization now uses a redirect callback

Google authorization now returns through /auth/google/callback.

Before sending the user to Google, Compass stores a short-lived authorization intent in browser session storage. That saved intent says whether the user was trying to sign in with Google or connect Google Calendar from inside an existing session.

When Google redirects back to Compass, the callback page:

• checks that the callback belongs to a saved Google authorization attempt
• rejects missing or expired authorization state
• validates that Google returned the required Calendar permissions
• routes the result to the correct backend endpoint
• returns the user to their original Compass page, or /day as a safe fallback
• shows a recoverable error if the flow cannot be completed

Backend now validates the Google redirect URI

The backend now derives the expected Google callback URL from the configured frontend URL plus /auth/google/callback.

When exchanging a Google authorization code, the backend rejects requests that do not use that expected callback URL. This keeps the code exchange tied to the Compass instance that initiated the flow.

Removed the old Google popup/overlay path

The old popup-oriented Google auth wrappers and blocking “complete Google sign-in” overlay were removed.

Google authorization now has one loading surface: the callback page that appears after Google redirects back to Compass.

Calendar connect still syncs local user-created events first

For an existing password-authenticated user connecting Google Calendar, Compass still tries to sync pending local events before redirecting to Google.

After Google returns successfully, Compass connects the Google account, refreshes user metadata, and refetches calendar events so the UI moves into the normal import/sync state.

Demo events are no longer uploaded into real accounts

Seeded demo events are now marked locally in IndexedDB.

That marker is used only in browser storage. When local events are synced into a real account, Compass:

• uploads user-created local events
• skips seeded demo events
• strips the local-only marker before anything is sent to the backend
• preserves the marker if a user edits a seeded demo event before signing in

This prevents sample events like onboarding/demo calendar entries from becoming real account data.

Docs were updated

The docs now describe the redirect-based Google flow, the new callback URL, and the demo-event sync behavior.

Updated areas include:

• auth acceptance notes
• Google sync acceptance notes
• password auth flow docs
• frontend runtime docs
• self-hosted Google Calendar setup docs
• domain language around Google authorization intent

Validation

• bun run test:web
• bun run test:backend
• bun run type-check