feat(calendar): pick a Google event color in the event editor (#244)

[jherforth]

Closes #244.

What

When you create or edit a Google event, the editor now has a Color row:

• the calendar's own color comes first, as "no color of its own";
• then Google's eleven event colors, in Google's order: Tomato, Flamingo, Tangerine, Banana, Sage, Basil, Peacock, Blueberry, Lavender, Grape, Graphite.

The choice is saved as the event's Google colorId. When you edit an event, its current color is already picked.

How

API. POST/PATCH /api/calendar-sources/:id/events take an optional color_id:

• '1'–'11' sets that color;
• null (on an edit) puts the calendar's color back;
• left out, the color isn't touched;
• anything else is a 400, and nothing is sent to Google.

Cached events carry color_id beside event_color. It's read from the raw_data that sync already stores, so there's no migration.

Custom labels are protected. The editor sends a color only when it was picked or changed. An event may wear a custom Google label, which the picker can't show, and saving a title change must not strip it. This rule is eventColorToSend in client/src/utils/googleEventColors.js, with its own tests.

Sync uses Google's current palette. Until now, sync turned a colorId into a hex through the API's /colors endpoint. That endpoint still returns the pre-2016 colors:

• Graphite comes back near-white (#e1e1e1), where Google's UI shows dark grey (#616161);
• Tomato comes back #dc2127, where the UI shows #d50000.

So picking Graphite in the editor would have shown a near-white event on the dashboard. Sync now resolves colorId through EVENT_COLORS in services/googleCalendar.js, the same eleven hexes the swatches use. A custom label's color still wins, as before. As a side effect, sync makes one fewer Google request per run.

Docs. features.md and backend-api.md are updated. I also put the "Per-event Google colors" bullet in features.md back together; its second half had drifted under "Idle auto-return".

Effect on existing installs

Events colored in Google with no label will now show Google's current shade instead of the older one. That means Google's UI and HomeGlow agree, which is the reason sync already preferred label colors. Events on their calendar's color, and non-Google sources, are unchanged.

Tested

• Server: npm test passes 358/358. There are new tests for:

  • color_id in create and update;
  • leaving the color untouched;
  • clearing it with null;
  • a 400 for 0, 12, 'red', a hex, or 3.5;
  • the palette;
  • parseEventColorId.

  The sync color tests were moved to the new palette.

• Client: npx vitest run passes (531 tests), and npm run check:i18n and npm run build succeed.

• Browser check: a Google-type source was seeded with a Graphite event and an uncolored one. There's no Google account here, so the save calls were intercepted to capture what the editor sends.

  • The day view shows Graphite as rgb(97, 97, 97) and the uncolored event in its calendar's orange.
  • Editing the Graphite event opens with Graphite picked. Saving a title change sends no color_id.
  • Picking Tomato sends "11", and picking "Calendar color" sends null.
  • A new event starts on "Calendar color", and picking Basil sends "10".
  • Enter on a focused swatch picks it.

Not tested against a real Google account. It's worth one real create/edit before release. In particular, it should confirm that colorId: null on a PATCH puts the calendar's color back.

🤖 Generated with Claude Code