feat: expand deck example with Overture buildings - #570

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@examples/deckgl/README.md`:
- Line 13: Update the README to avoid a brittle hardcoded count and to correct
the tooltip claim: change the phrasing in examples/deckgl/README.md (the
sentence referencing "It renders 48,451 ... building footprints") to a resilient
form such as "~48k building footprints (Zurich buildings dataset, currently
48,451 rows)" and either remove "name" from the tooltip description or add
support for it in the code; if you choose the latter, modify the BUILDINGS_QUERY
projection in MapView.tsx (the BUILDINGS_QUERY constant) to include the name
field and update the tooltip handler in the MapView component to render name
along with class and height so the README matches the implementation.

In `@examples/deckgl/src/components/MapView.tsx`:
- Around line 30-36: The BUILDINGS_QUERY in MapView.tsx currently selects only
class, height, and geometry, but the README and tooltip expect a building name;
update the BUILDINGS_QUERY to include the name field (e.g., names.primary AS
name) and update the tooltip handler that reads row.class and row.height to also
read and render row.name so the tooltip shows name, class, and height
consistently (or, if you prefer to remove name support, update README
instead—prefer adding the name to BUILDINGS_QUERY and the tooltip).
- Around line 217-219: The current airportsStatus assignment (airportsStatus =
majorAirportsState ?? airportsState) can hide an airportsState error when
majorAirportsState is defined; change the logic to pick the "worst" status
between airportsState and majorAirportsState (e.g., error > loading > ready) so
any error or loading on the primary airports layer is surfaced; implement this
by adding a small helper or inline comparator that examines airportsState.status
and majorAirportsState.status and returns the state with the highest-priority
(worst) status, then assign airportsStatus using that helper instead of the
nullish-coalescing expression.
- Around line 216-228: The hardcoded fallback 48451 in buildingCount is brittle
and asymmetric with airportCount; change buildingCount so it follows the same
pattern as airportCount (i.e., return null unless buildingState?.status ===
'ready') by removing the magic number and using the prepared.table.numRows only
when buildingState.status === 'ready' (referencing datasetStates, buildingState,
buildingCount, and airportCount) and ensure the UI that consumes buildingCount
handles null the same way it does for airportCount.

In `@examples/deckgl/src/index.css`:
- Around line 1-8: The `@keyframes` shimmer rule is placed between `@import`
statements which violates CSS ordering and the shimmer animation appears unused;
fix by moving or removing it: ensure both `@import` 'tailwindcss' and `@import`
'@sqlrooms/ui/tailwind-preset.css' appear first, then either delete the
`@keyframes` shimmer block if not used anywhere or relocate the `@keyframes` shimmer
definition after all `@import` directives (and update any component using
"shimmer" if you keep it).

In `@packages/deck/src/DeckJsonMap.tsx`:
- Around line 210-213: The effect depends on onDatasetStatesChange identity and
can trigger render loops for callers passing unstable inline callbacks; update
DeckJsonMap to avoid this by capturing the latest callback in a ref (e.g.,
create cbRef for onDatasetStatesChange, keep it updated in an effect, and invoke
cbRef.current(datasetStates) in the datasetStates-only effect) or alternatively
add README docs requiring consumers to pass a stable callback via useCallback;
reference the onDatasetStatesChange prop, the existing useEffect that currently
depends on [datasetStates, onDatasetStatesChange], and the datasetStates value
from usePreparedDatasetStates when making the change.

In `@packages/deck/src/prepare/wkbDecoder.ts`:
- Around line 49-72: parseWKBHeader currently misses ISO ZM (3000–3007)
geometries causing wrong hasZ/hasM, base and coordBytes; update parseWKBHeader
to detect the 3000–3007 ISO range (set both hasZ and hasM true) and normalize
base by subtracting 3000 for that range before the existing 2000/1000
adjustments, and ensure the EWKB bit checks for hasZ/hasM still apply (i.e.,
hasZ = EWKB Z bit || ISO 1000 range || ISO 3000 range; hasM = EWKB M bit || ISO
2000 range || ISO 3000 range) so coordBytes and geomType (base) are computed
correctly.
- Around line 184-290: tryPromotePolygonTable currently only accepts WKB_POLYGON
/ 'Polygon' and will blow up on MultiPolygon rows; update tryPromotePolygonTable
to also handle WKB_MULTIPOLYGON and geom.type === 'MultiPolygon' by iterating
each polygon in the MultiPolygon and pushing each polygon's rings into
ringOffsetsList (and still increment polygonOffsets[i] once per original row) so
rings from all constituent polygons are flattened into the same row's ring list;
also add the same WKB_MULTIPOLYGON branch when reading from the binary hdr
(check geomType === WKB_MULTIPOLYGON and parse nested polygon counts/offsets
accordingly). As a complementary safety change, ensure the promotion path is
tolerant by making toGeoArrowLike (or getGeoArrowLayerData) return null on any
unsupported geometry type instead of throwing, or broaden
supportsGeoArrowPromotion / getSampleWKBGeomType / getSampleGeometry to scan
multiple non-null rows when deciding compatibility so mixed Polygon/MultiPolygon
columns are detected earlier and fall back to GeoJSON-binary.

---

Outside diff comments:
In `@packages/deck/src/json/layerCompatibility.ts`:
- Around line 87-105: The manifest wrongly sets allowGeoArrowPromotion: true for
GeoArrowPathLayer and GeoArrowTripsLayer even though prepare/wkbDecoder.ts only
implements promotion for POINT_LAYERS and POLYGON_LAYERS; either remove (or set
to false) the allowGeoArrowPromotion flag in the GeoArrowPathLayer and
GeoArrowTripsLayer entries (referencing the allowGeoArrowPromotion property and
the GeoArrowPathLayer/GeoArrowTripsLayer objects in layerCompatibility.ts) so
the config matches supportsGeoArrowPromotion in wkbDecoder.ts, or alternatively
implement LineString promotion by adding a LINE_LAYERS set and the corresponding
promotion logic in supportsGeoArrowPromotion inside wkbDecoder.ts to support
LineString/MultiLineString promotions for Path/Trips layers.

In `@packages/deck/src/prepare/wkbDecoder.ts`:
- Around line 369-405: supportsGeoArrowPromotion is unsafe because
getSampleGeometry/getSampleWKBGeomType only look at the first non-null row and
can misreport column homogeneity; update supportsGeoArrowPromotion (used in
wkbGeometryDecoder) to sample multiple rows instead of relying on a single
sample: for the given table and columnName call
getSampleGeometry/getSampleWKBGeomType repeatedly (or iterate rows lazily) up to
a reasonable cap (e.g., 100 or full table) and return true only if every
non-null sampled geometry matches the expected type for POINT_LAYERS (compare to
'Point' or WKB_POINT) or POLYGON_LAYERS (compare to 'Polygon' or WKB_POLYGON);
if any mismatch is found return false so toGeoArrowLike will not attempt
promotion for mixed types. Ensure you reference supportsGeoArrowPromotion,
getSampleGeometry, getSampleWKBGeomType, POINT_LAYERS, POLYGON_LAYERS,
WKB_POINT, WKB_POLYGON, and toGeoArrowLike in the change so reviewers can locate
the logic.
- Around line 297-356: In tryPromotePointTable update handling of
null/unparseable geometries so the child coordinates are set to NaN instead of
left as 0: whenever you mark isNull[i]=1 (for raw == null, failed
parseGeometryValue, or any branch where you skip writing coordinates) also
assign xyValues[i*2]=Number.NaN and xyValues[i*2+1]=Number.NaN; keep the
existing nullCount increment and validity bitmap logic, and leave the success
paths (WKT Point and WKB Point branches) unchanged—this ensures the
FixedSizeList child uses NaN for null points per the GeoArrow spec before
building floatData/geomData and returning buildPromotedResult.

---

Nitpick comments:
In `@examples/deckgl/src/components/MainView.tsx`:
- Around line 7-10: Promote the magic string 'airports' to a shared constant
(e.g., AIRPORTS_TABLE_NAME) in the same module that exports BUILDINGS_TABLE_NAME
(dataSources.ts) and replace the literal in MainView's useRoomStore selector
(currently using s.db.findTableByName('airports')) with that constant; also
update any other usages (e.g., MapView and store.ts where tableName: 'airports'
is set) to reference AIRPORTS_TABLE_NAME so the table name is defined in one
place and cannot drift.

In `@examples/deckgl/src/components/MapView.tsx`:
- Line 79: The hardcoded color-scale domain in BUILDINGS_LAYERS should be
replaced with a dynamic value computed from buildingState.prepared.table when it
is ready: compute the min/max height (either via a SQL MIN/MAX probe against
buildingState.prepared.table or by reading the Arrow column and computing
min/max) and pass that [min,max] into BUILDINGS_LAYERS using useMemo so the
layer updates when data changes; while buildingState.prepared.table is not
ready, fall back to a sensible default domain to avoid breaking the legend
semantics.

In `@examples/deckgl/src/store.ts`:
- Line 22: The initializationQuery string is missing a trailing semicolon;
update the initializationQuery value (symbol name: initializationQuery in the
store module) to terminate the final statement with a semicolon (e.g., 'LOAD
httpfs; LOAD spatial;') so it matches other SQLRooms initialization queries and
avoids issues if the string is later concatenated.

In `@packages/deck/src/DeckJsonMap.tsx`:
- Around line 107-124: The computed but unused loadingDatasets in
renderDatasetStatusOverlay is dead code; remove the loadingDatasets aggregation
(the Object.entries(...).filter(...).map(...) block) to eliminate the unused
variable, or if you intended to show loading state, instead reference
loadingDatasets when rendering the overlay alongside failedDatasets; update
renderDatasetStatusOverlay (and any JSX it returns) to either drop
loadingDatasets entirely or include it in the returned overlay so the variable
is actually consumed. Ensure references are to renderDatasetStatusOverlay,
loadingDatasets, failedDatasets, and PreparedDeckDatasetState.

In `@packages/deck/src/prepare/wkbDecoder.ts`:
- Around line 85-97: In buildNullBitmap, the expression "(bitmap[i >> 3] ?? 0)"
is unnecessary and causes an extra runtime branch; replace it with a non-null
assertion or direct in-place OR to avoid the nullish coalescing. Locate function
buildNullBitmap and change the write to the bitmap bucket (indexed by i >> 3) to
use a non-null assertion (e.g., bitmap[i >> 3]!) or perform an in-place OR on
that index so the code becomes "bitmap[index] = bitmap[index] | (1 << (i & 7))"
(or equivalently "bitmap[index] |= ..."), which satisfies
noUncheckedIndexedAccess without the dead branch.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@examples/deckgl/src/components/MapView.tsx`:
- Around line 88-122: The AIRPORT_LAYERS definition currently hardcodes the
dataset key as the string 'airports' in the _sqlroomsBinding for the first
layer; change that binding to use the imported AIRPORTS_TABLE_NAME constant
instead so it always matches the dataset key used when registering datasets.
Locate the AIRPORT_LAYERS constant and update the first layer's _sqlroomsBinding
from {dataset: 'airports'} to reference AIRPORTS_TABLE_NAME (the
already-imported symbol) so the layer binding remains correct if the table name
changes.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@examples/deckgl/package.json`:
- Line 33: The package.json pins eslint-plugin-react-hooks to ^5.2.0 which is
incompatible with React 19.2; update the dependency entry
"eslint-plugin-react-hooks" to a v6+ release (e.g., ^6.1.1 or ^7.1.1) so ESLint
uses the updated hook semantics required by React 19.2, then run install to
update lockfiles.