Sync the runtime SDK types with colours and note mobile tints only the badge

plugin-sdk/src/index.ts

@@ -601,6 +601,12 @@ export interface DayScheduleProvider {
  * them, or name regions individually for finer control — e.g. a bold badge marking the
  * leg with the activity list left plain, so a dense day stays easy to read.
  *
+ * The regions map onto the DESKTOP day card's layout. The mobile day strip is built
+ * differently and honours only the badge region, as the day chip's tint; header and
+ * activity tints do not render on phones. So treat the badge (or the shorthands, which
+ * include it) as the one region every user sees, and the finer regions as desktop
+ * refinement.
+ *
  * Colour is decoration, not information: pair it with `label` (and with a
  * dayScheduleProvider row where it matters) so the meaning survives for anyone who
  * cannot tell your legs apart by hue. */

server/src/nest/plugins/runtime/plugin-sdk.ts

@@ -551,14 +551,23 @@ export interface DayScheduleProvider {
 
 /** A colour the host paints into one day card in the Plan sidebar (and into that day's
  * mobile chip) — so a trip split into legs shows its leg membership while you scroll
- * the itinerary. Tone only, never a hex: the host picks the alpha per theme and per
+ * the itinerary. A region takes a `tone` from the shared palette or the plugin's own
- * region. The card has three separately tintable regions; `tone` colours all of them. */
+ * `#rrggbb` `color` (exactly six hex digits — anything else is ignored); either way
+ * the host picks the alpha per theme and per region and clamps a colour's lightness,
+ * so the tint always lands as a readable wash. The card has three separately tintable
+ * regions; the `tone`/`color` shorthands fill every region not named, and `color` wins
+ * over `tone` at the same level. The regions follow the DESKTOP card — mobile honours
+ * only the badge (as the day chip). */
 export interface DayTintContribution {
   dayId: number;              // must be a day of the requested trip
   tone?: ContributionTone;    // shorthand for every region not named below
+  color?: string;             // own-colour shorthand, `#rrggbb` only
   badgeTone?: ContributionTone;    // the day-number badge (and the mobile day chip)
+  badgeColor?: string;
   headerTone?: ContributionTone;   // the day header row
+  headerColor?: string;
   activityTone?: ContributionTone; // the expanded activity list
+  activityColor?: string;
   label?: string;             // optional tooltip on the day (≤60 chars)
 }
 export interface DayTintProvider {

wiki/Plugin-Cookbook.md

@@ -564,6 +564,11 @@ return days.map((d) => ({ dayId: d.id, headerTone: legTone(d), activityTone: ove
 
 A region you never name is not tinted and renders exactly as it does without your plugin.
 
+The regions follow the **desktop** day card. On mobile only the badge renders, as the
+day chip's tint — header and activity tints do not show on phones. Keep whatever every
+user must see on the badge (or the shorthands, which include it), and treat the finer
+regions as desktop refinement.
+
 `label` becomes the day's tooltip. A day takes at most one contribution and it is
 resolved **whole** — within your list the first entry for a day wins, and if another
 plugin also tints that day the first granted provider wins outright, so days never