Google Calendar: the "primary" alias is accepted by the configurator but rejected on submit

[darrinm]

What happens

Configuring a Google Calendar connection whose calendar is primary can only fail. The
configurator opens with the calendar set to primary and lets you proceed, but submitting is
rejected with:

Google Calendar bindings must use a stable calendar ID, not the account-relative "primary" alias.

So the error surfaces at the end of the flow, after the account and options have been chosen, rather
than being prevented or reconciled earlier.

Why it comes up

primary is Google Calendar's own canonical alias for the signed-in user's default calendar (the
Calendar API accepts calendarId=primary everywhere), so it's the natural value for anything that
constructs a calendar reference without first resolving it — including an AI agent's connection
request, which is how I hit it (the calendar field was pre-filled with primary; I didn't type it).

The two halves that disagree

• The backend rejects the alias outright:
  packages/gatekeeper-google/src/resources.ts — parseCalendarUrl throws when
  calendarId === "primary" (added in Lay the foundation for a Google Drive gatekeeper #286). This is a reasonable rule on its own: primary
  resolves to a different calendar per account, so it isn't a stable binding target.
• The configurator (packages/gatekeeper-google/src/configurator/calendar-configurator-ui.tsx)
  accepts/presents primary as the calendar value, so the request reaches submit before the rule
  applies.

The net effect is that a calendar reference of primary is representable up to the point of
submission but never acceptable.

Steps to reproduce

1. Start a Google Calendar connection where the calendar is primary (e.g. a request/flow that
   proposes primary rather than a calendar picked from the list).
2. Complete the account selection and options.
3. Submit → the "stable calendar ID, not the account-relative primary alias" error.

Impact

The account's primary calendar — the most common one to connect — can't be connected through a flow
that names it as primary; the failure only appears after the whole form is filled in.

Environment

Observed on a fork tracking main; the relevant code (parseCalendarUrl and the calendar
configurator) is unmodified from upstream.