feat(vegalite): add Calendar Heatmap template

[Y.Lab3 (zl190)]

What

Adds a Calendar Heatmap template to the Vega-Lite backend, bringing it to
parity with the ECharts backend (ecCalendarHeatmapDef).

ECharts has a first-class calendar coordinate system; Vega-Lite has none. The
ECharts calendar.ts header notes that VL "has no first-class calendar; would
fake it with rect + computed week/day fields." It turns out no computed fields
are needed — timeUnit expresses the GitHub-style grid directly from a single
date field:

• x → timeUnit: 'yearweek' (one ordinal column per calendar week)
• y → timeUnit: 'day' (Sun–Sat rows, Monday-first to match the ECharts dayLabel.firstDay = 1)
• color → aggregate: 'sum' collapses rows sharing a calendar day into one cell

so the same date field drives both axes with no core changes.

Encoding

channel	role
x (date)	the date of each cell
color (quantitative)	the cell value; falls back to a per-day count when omitted

Scheme handling

Mirrors the ECharts template's encodingActions: named Vega-Lite schemes
(viridis/blues/greens/reds/oranges/purples) pass through as
scale.scheme; github has no built-in Vega-Lite equivalent, so it resolves to
an explicit scale.range (the same low→high ramp the ECharts template uses).

Changes

• vegalite/templates/calendar.ts — new vlCalendarHeatmapDef
• register in vlTemplateDefs (Tables & Maps group, next to Heatmap)
• tests/calendar-vegalite.test.ts — 8 cases: registry, dual-axis timeUnit
  projection, Monday-first row order, per-day sum, count fallback, github
  range vs named scheme, and cross-backend parity. The assembled spec is also
  verified through vl.compile.
• regenerate docs/reference-vegalite.md; move Calendar Heatmap from the
  SKILL.md "ECharts adds" list into the shared template table (+ synced bundled
  asset)

Open questions

• Weekday-first convention: rows are Monday-first to stay consistent with the
  shipped ECharts calendar (dayLabel.firstDay = 1), so the same spec renders the
  same way on both backends. This differs from GitHub's own contribution graph,
  which starts the week on Sunday. I kept parity with the existing backend rather
  than mirroring GitHub. If you'd rather the canonical calendar follow GitHub
  (Sunday-first), that's a cross-backend convention change — ECharts and Vega-Lite
  together — which I'm happy to do as a separate PR so the two backends stay aligned.
• Multi-year spans: yearweek produces a continuous band that widens with
  range; the ECharts template shrinks its cell size instead. This PR relies on
  labelOverlap + the container width. Happy to add explicit cell sizing if you
  prefer.
• Recommendation layer: I did not add a Calendar recommendation rule (a
  temporal x + quantitative color heuristic). Let me know if you'd like one.

[Chenglong Wang (Chenglong-MS)]

Y.Lab3 (@zl190) wondering if you want to update and test it with the latest dev? Thanks!

[Y.Lab3 (zl190)]

Rebased onto dev (d1dc86d) and re-ran everything.

One conflict, in vegalite/templates/index.ts: donutChartDef landed in the same two lines the Calendar registration touches. Both are kept — "Circular" keeps donut, "Tables & Maps" gets the calendar entry next to Heatmap.

docs/reference-vegalite.md is regenerated via npm run gen:reference; its header count moved 35 → 36.

Verified on the rebased branch:

• tests/calendar-vegalite.test.ts — 8/8
• npm run test:js — 953 passing (50 files)
• npm run test:mcp — 67 passing
• npm run typecheck — clean
• npm run lint — 0 errors (30 warnings, all pre-existing, none in the new file)

The diff is unchanged in shape: 6 files, +227/−4.

One open question this surfaces. scripts/gen-chart-reference.ts describes the ECharts backend as covering structures "outside Vega-Lite's scope: ... and calendar heatmap", and that sentence is generated into docs/reference-echarts.md. If this merges, calendar heatmap is no longer in that set. I can add a commit dropping it from the list. But if that sentence records a deliberate boundary — that a calendar belongs to the ECharts backend — I'd rather you make that call explicitly than have it edited as a side effect of this PR. Same goes for the "Weekday-first convention" question in the description.