fix(cli): every os explain catalog example parses against its own schema (#16924)

The catalog in `packages/cli/src/commands/explain.ts` is hand-maintained and
does not derive from the spec, so its examples drifted behind the schemas they
claim to demonstrate. The sweep landed for #14811 parses every entry's
`example` against its real schema and pinned each failure as an `it.fails`
xfail. This corrects the six entries that carried one, disposes of a seventh
that had no type to check against at all, and promotes every xfail to a plain
assertion — the ledger is now empty.

- object      select `options` are objects (`{ label, value }`), not strings
- field       the prose row that was the source of that error: `string[]` ->
              `SelectOption[]`, and the example demonstrates the real shape
- view        `ViewSchema` is the per-object CONTAINER; a single view's keys
              live inside a `list` / `form` / `listViews` / `formViews` slot
- agent       `tools` was removed in spec 17 (ADR-0064) with no key its value
              moves to — teach `skills`, `model` as an object, and the
              required `label` / `instructions`
- app         nav items need `id` plus the discriminant's own target key
              (`objectName` / `dashboardName`); `logo` / `defaultRoute` are
              not AppSchema keys
- dashboard   widgets bind a `dataset` and select `dimensions` / `values`
              (ADR-0021); `'chart'` is not a widget type; there is no
              dashboard-level `layout`
- action      `objectName`, `confirmText`, and `target` for a flow action;
              `"button"` is not in the type enum
- trigger     ADR-0088 retired the kind and its `TriggerSchema` never existed
              — the entry becomes an explicit redirect to `hook` and a
              `record_change` flow, the shape `workflow` already uses


Claude-Session: https://claude.ai/code/session_015QE8qk46e5CHJxyQEUjbf8

Co-authored-by: Claude <noreply@anthropic.com>

Author: claude[bot]

.changeset/cli-explain-catalog-parses-against-spec.md

@@ -0,0 +1,16 @@
+---
+"@objectstack/cli": patch
+---
+
+`os explain` stops teaching shapes the spec rejects: all seven remaining broken catalog entries are corrected, and the sweep's xfail ledger is now empty.
+
+The catalog in `packages/cli/src/commands/explain.ts` is hand-maintained and does not derive from the spec, so its examples drifted behind the schemas they claim to demonstrate. The sweep landed for #14811 parses every entry's `example` against its real schema and pinned each failure as an `it.fails` xfail naming a card. This corrects all six that carried one, disposes of the seventh (an entry with no type at all), and promotes every xfail to a plain assertion — leaving the ledger empty, so the identical error cannot return silently.
+
+- **`object`** — select `options` are sampled as objects. A bare `['open', 'closed']` was rejected twice over (`expected object, received string`); each option is `{ label, value }`, where `value` is the stored lowercase machine identifier.
+- **`field`** — the prose half of the same defect, which the sweep structurally cannot see: the optional-property table documented `options` as `type: 'string[]'`, and that row is where the `object` example's error came from. It now names `SelectOption[]` and spells the member shape out, and the entry's example demonstrates the real option list instead of a plain text field.
+- **`view`** — the entry taught the wrong LEVEL, not a drifted key name. `ViewSchema` is the per-object view CONTAINER (`list` / `form` / `listViews` / `formViews`); a flat list-view literal is rejected wholesale. The tables now document the container, and the example shows a single view's own keys inside a slot.
+- **`agent`** — `tools` was removed in `@objectstack/spec` 17 with no key its value moves to (ADR-0064: an agent reaches exactly the tools its surface-compatible skills declare). The entry now teaches `skills`, `model` as the configuration OBJECT it is, and the required `label` / `instructions` it had listed as optional or omitted. Two rows naming keys the schema does not have (`objects`, a top-level `temperature`) are gone.
+- **`app`** — navigation items carry `id` plus the discriminant's own target key (`objectName` / `dashboardName`), not a bare `object` / `dashboard`. The table's `logo` and `defaultRoute` rows were the same class of error — neither is an `AppSchema` key, and `logo` is now rejected by name in favour of `branding`.
+- **`dashboard`** — widgets bind a `dataset` and select `dimensions` / `values` by name (ADR-0021); the pre-ADR-0021 inline analytics shape (`object` + `groupBy` + `aggregate`) was removed, and `'chart'` is not a widget type at all — the enum names the concrete mark. `label` and `widgets` move to required, where the schema has them, and the non-existent dashboard-level `layout` row is dropped for the per-widget `layout: { x, y, w, h }`.
+- **`trigger`** — not a wrong example but an entry with no type to check against. ADR-0088 §1 retired the `trigger` metadata kind and records that its enum comment referenced a `TriggerSchema` that never existed. The entry becomes an explicit redirect, the same shape the `workflow` entry already uses, pointing at the two delivered mechanisms the ADR names: a `hook` for synchronous in-transaction data-layer logic, a `record_change` flow for asynchronous automation. Its `docsPath` moves off a page that does not exist.
+- **`action`** — `object` is `objectName`, `confirmation` is `confirmText`, and a `type: 'flow'` action names its flow in `target` (there is no `flow` key, and none was suggested, which is why the entry could not simply be renamed). The required table also advertised a `"button"` action type that is not in the enum, and a `url` key the schema does not have.