ci(e2e): enable Google Calendar E2E suites in workflow

[h4yfans]

Summary

Enables the two Calendar E2E suites landed in #291 to actually run in CI by wiring the GOOGLE_CALENDAR_E2E_* repo secrets into the Playwright Electron job.

What changes: one env: block added to the "Run Electron E2E tests" step in .github/workflows/e2e.yml. 9 lines.

GOOGLE_CALENDAR_E2E: '1'
GOOGLE_CALENDAR_E2E_REFRESH_TOKEN: ${{ secrets.GOOGLE_CALENDAR_E2E_REFRESH_TOKEN }}
GOOGLE_CALENDAR_E2E_CLIENT_ID: ${{ secrets.GOOGLE_CALENDAR_E2E_CLIENT_ID }}
GOOGLE_CALENDAR_E2E_CLIENT_SECRET: ${{ secrets.GOOGLE_CALENDAR_E2E_CLIENT_SECRET }}

What this unblocks

Suite	Before	After
calendar-google-two-way-sync.e2e.ts (Google → Memry)	skipped (no flag)	runs, ~7s
calendar-google-writeback.e2e.ts (Memry → Google)	skipped (no flag)	runs, ~7s
calendar-push-channels.e2e.ts (webhook round-trip)	skipped (by design)	skipped (by design)

Push-channels remain skipped until the staging Memry sync-auth user is provisioned — unchanged from #291.

Safety

• Forks: can't access secrets → env vars resolve to empty strings → CREDS_PRESENT check fails → test.skip fires at the describe level. Forked PRs still pass E2E.
• Exposure: secrets are scoped to the one Playwright step, not the whole workflow. Easy to remove if we ever split the job.
• Cost: per CI run on main, Calendar suites make ~7 Google API calls (auth refresh + 1 event create + 1 sync + 1 GET + 1 delete × 2 suites). Negligible against Google's quota.

Out of scope (follow-up)

Current triggers on e2e.yml:

```yaml
on:
push:
branches: [main]
workflow_dispatch:
```

Calendar E2E will only run post-merge to main. To actually gate PRs on Calendar health, add a pull_request: trigger. I left this out because:

• It's a bigger decision (every PR burns minutes + Google API calls, even unrelated ones)
• Current behavior already catches regressions on main fast enough that devs can revert before they cascade
• If you want PR-gating, trivial follow-up: add pull_request: with an optional paths: filter on apps/desktop/** to scope the cost

Testing this PR

Can't — this PR changes the workflow, but the workflow only triggers on push-to-main. Options for validation:

1. Merge, watch the next push-to-main CI run — pragmatic, the change is 9 lines of YAML
2. Manual workflow_dispatch on this branch post-merge to exercise before the next feature lands
3. One-off: temporarily add pull_request: trigger in a throwaway commit — overkill

Recommending option 1. The change is small and review-verifiable.

Test plan

• Workflow YAML passes GitHub's parser (PR creation implies validation)
• Reviewer: confirm the three secrets are present in repo Settings → Secrets → Actions (they were, as of 2026-04-20 06:44 UTC)
• Post-merge: next main-branch push should show the Calendar suites executing (not skipping) in the E2E job logs