finding(react): bridgeListView's mapDensity carries four rowHeight spellings no spec-valid list view can hold #4352

Found while type-checking @object-ui/react's tests for #4040 (tranche 4, PR #4351). Observation-class: nothing a user hits today, and no fix is proposed here.

What

packages/react/src/spec-bridge/bridges/list-view.ts maps a list view's rowHeight onto the renderer's density with a hand-written table of nine keys:

compact, short, comfortable, spacious, small, medium, large, tall, extra_tall

RowHeightSchema in @objectstack/spec admits five:

short | compact | medium | tall | extra_tall

So comfortable, spacious, small and large are unreachable from any spec-valid input. The bridge's own parameter type says so — it is Partial< ListView >, i.e. the spec shape — and mapDensity widens it back to rowHeight?: string to accept them.

Why it survived

SpecBridge.test.ts asserted three of the four (comfortable, spacious, small) as though they were live capability, and that file was compiled by nothing: the package's build tsconfig excludes tests and no other tsc invocation read them. Type-checking the tree is what surfaced it — the fixture would not compile against the type the function declares.

PR #4351 re-spells the fixture canonically and now covers all five spec values (gaining medium and tall, which the suite never had). It deliberately does not touch the source: deleting a lenient branch is a behaviour change for any host still passing a legacy spelling, which is a separate decision from the type-check graduation.

The decision, when someone takes it

This is AGENTS.md #0.1 territory (fix the metadata, not the renderer — one strict contract beats N dialects), so the default answer is to delete the four dead keys and let a non-spec rowHeight fall through to undefined density. The counter-consideration is empirical, not theoretical: whether any live metadata still authors comfortable/spacious, since the ADR-0087 conversions rewrote a lot of older pages. Worth a grep across the example apps and the console's own view metadata before removing.

Related: the same PR found ListColumn.link / .action asserted as { href } / { type } objects when the spec declares boolean / string; the bridge forwards them verbatim, so those assertions only ever proved pass-through. Re-spelled in #4351.