finding(plugin-timeline): a gantt row that is a non-null primitive or an array (`items: [0]`, `['x']`, `[true]`, `[[]]`) draws an unlabelled empty row silently — while `validate` now refuses it

[os-litant]

Found while implementing #7164 (maintainer ruling A+). Not repaired there: the ruling fixed the render-time door at exactly three shapes — items not an array, a null row, a row whose items is a truthy non-array — and required the card's CONTROL rows, which include items: [0] and items: [[]], to keep DRAWING. So this corner was deliberately left as measured, and it is recorded here rather than widened silently.

What is wrong

A row that is a non-null primitive or an array has no .items and no .label, so the gantt walk reads undefined off it and draws an EMPTY, UNLABELLED row. Nothing tells the author. Measured in render through the real TimelineRenderer, on a67abdc88 (main) and on the #7164 branch at 8e1dc8274 — identical readings:

items: [0] DREW bars=0 axisCells=1
items: [[]] DREW bars=0 axisCells=1

(items: ['x'] and items: [true] take the same path: 'x'.items and true.items are undefined.) That is consumer-side tolerance of the kind #6750 / #6759 refused elsewhere on this branch: authored content that is not a row is dropped without a word.

After #7164, validate REFUSES every one of these at authoring time (items[0]: expected object, received number / received array), so the declared accept set and the rendered one disagree in this corner. The direction is the safe one — the renderer is more lenient than validate, never the reverse, and it does not crash — but declared and rendered still differ.

Options

• A — refuse at render-time too, through the timeline.gantt.unusableRange.malformedRow key finding(plugin-timeline): a gantt row that is null, or whose items is a truthy non-array, crashes the render — findUnusableGanttDate reads the walk defensively and calculateDateRange reads it bare #7164 added: change classifyGanttRows's row predicate from row == null to "not an object", and the existing copy already reads correctly (items[0] is 0, which is not a row shape). One predicate, no new key, no new packs. It changes the render accept set beyond the A+ ruling, so it is a ruling, not a dev's call.
• B — leave it: validate is the door that matters at authoring, and the renderer's leniency here is harmless.

Recommendation: A, on the family's refuse-not-tolerate principle (#6750, #6759, #7164) — an AI-authored document that emits a scalar where a row belongs should be told so on screen, not shown a blank row.

Blocked-by: #7164 (the predicate and the key both land there).