[P1] Finish ADR-0021 analytics migration (chart view / dashboard+Studio / report)

[os-zhuang]

Part of the metadata liveness audit umbrella #1878 (P1 — finish ADR-0021).

Problem

ADR-0021 moved the analytics spec to dataset + values/dimensions, but renderers and Studio still read the removed legacy shape (object/categoryField/valueField/aggregate, xAxisField/yAxisFields/aggregation). The result: a spec-compliant chart/dashboard/report renders nothing, and Studio emits widgets the spec rejects. (This is the same debt that invalidated the showcase dashboard/report seeds.)

Checklist

• Chart view variant — ListView.tsx:1413 / ObjectView.tsx:754 read legacy xAxisField/yAxisFields/aggregation; migrate to dataset/dimensions/values.
• Dashboard renderer + Studio WidgetConfigPanel — still author/read legacy object/categoryField/valueField/aggregate while dashboard.zod.ts:153 declares dataset+values required; migrate both read and authoring paths.
• Report chart — dead on the dataset path; migrate. ReportColumnSchema/ReportGroupingSchema/ReportChartSchema are obsolete type-only re-exports — remove or repoint.
• Re-validate / regenerate the showcase dashboard + report seeds against the migrated shape.

Evidence

• docs/audits/2026-06-dashboardschema-property-liveness.md, 2026-06-reportschema-property-liveness.md, 2026-06-viewschema-property-liveness.md, 2026-06-datasetschema-property-liveness.md
• ListView.tsx:1413, ObjectView.tsx:754, dashboard.zod.ts:153
• ADR-0021

[os-zhuang]

Chart renderer migration (this audit's recommendation #1) — DONE.

Post-ADR-0021 the spec exposes only dataset/dimensions/values, but the chart renderers still read the removed legacy xAxisField/yAxisFields/aggregation, so a spec-compliant chart view rendered nothing. Fixed in objectui:

• fix(chart): render ADR-0021 dataset-bound chart views (framework#1890) objectui#1757 — ObjectChart now runs the governed queryDataset path when a chart binds to a dataset; ListView (type:'chart') + both ObjectViews emit the dataset shape; legacy aggregate kept as a deprecated fallback. Browser-verified: showcase Task → "Hours by Status (Chart)" (binds showcase_task_metrics) now renders a bar chart with live data (was blank).
• feat(chart): grouped series for multi-dimension dataset charts (#1759) objectui#1761 — multi-dimension charts: a shared buildChartSeries pivots the second dimension into grouped series (so ['status','priority'] renders grouped/coloured bars, not just a repeated x-axis). Applied to both ObjectChart and the dashboard DatasetWidget.

Surfaced en route: objectstack-ai/objectui#1760 — app-shell tsc build debt under full turbo build (turbo-cache-masked), unrelated to chart code.

Remaining viewschema-audit items are separate and NOT covered here: (#2) form-variant scope (wizard/split/drawer/modal only partially wired) and (#3) bulkActions/batchActions + groups/sections key drift.

[os-zhuang]

Form-variant scope (recommendation #2) — investigated + partly fixed.

Key finding (corrects the audit's framing): ObjectForm already implements every variant — TabbedForm / WizardForm / SplitForm are real components, and drawer/modal fall through to DrawerForm/ModalForm. The "degrade to stacked sections" the audit saw is the metadata-admin SchemaForm path, not ObjectForm. The real problem was that entry points never passed the layout through.

Fixed (objectstack-ai/objectui#1762): the full-page record form (RecordFormPage, :objectName/new + record/:id/edit) hard-coded formType:'simple'; it now reads the form view's type+sections and forwards them. Browser-verified: showcase_task/new renders a tabbed form (Overview/Schedule/Details, switching works).

Modelling debt (M2 — needs a small ADR). formType conflates two orthogonal dimensions:

• layout: simple / tabbed / wizard / split
• presentation container: drawer / modal

The real modal create/edit entry points (AppContent, useActionModal) set formType:'modal', so a modal form cannot also be tabbed — one field can't hold both. So tabbed/wizard only work where formType is set directly to them (the full-page route). Fully honouring layouts inside modal/drawer surfaces needs formType split into layout ⊥ presentation. Also: split is conceptually redundant (master-detail is already covered by subforms + ListView's split-detail open mode) — candidate for removal during the re-model.

Remaining viewschema-audit item: (#3) bulkActions/batchActions + ObjectView form-adapter key drift → filed separately.