feat: Deck.gl + geoarrow layers integration - #549

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

Inline comments:
In `@examples/deckgl-mosaic/README.md`:
- Line 15: Replace the typographic right single quote in the phrase "Mosaic’s"
with a straight ASCII apostrophe to match the repo's documentation style; search
for the string "Mosaic’s" in the README where the sentence mentions the global
Coordinator and DeckJsonMap and change it to "Mosaic's" so the prose is
consistent with other docs.

In `@packages/color-scales/README.md`:
- Around line 253-264: The README documents the wrong deck JSON function
discriminator (`sqlroomsColorScale`) causing integration breakage; update the
text to state the actual deck function discriminator `@@function: 'colorScale'`
(while keeping references to ColorScaleConfig, getFillColor/getLineColor and
MosaicColorLegend) so examples and compatibility guidance use
`{"@@function":"colorScale", ...}` instead of `sqlroomsColorScale`.

In `@packages/color-scales/src/scale.ts`:
- Around line 399-404: The current guard returns createNullColorAccessor when
numericValues is empty, which incorrectly disables explicit-domain
sequential/diverging/quantize and threshold scales; instead, only treat empty
samples as fatal for scales that require sampling (auto-domain or quantile).
Change the logic around
getNumericValues/createNullColorAccessor/getNumericScale: compute numericValues,
then if numericValues is empty check colorScale.type and colorScale.domainMode
(or the equivalent properties used to denote 'auto' vs explicit and 'quantile'
vs other kinds) and only return createNullColorAccessor(nullColor) for
auto-domain or quantile scales; otherwise proceed to call
getNumericScale(colorScale, numericValues) and build the accessor. Apply the
same conditional change to the other identical block referenced (the section
around lines 448-453 that also uses numericValues/getNumericScale).
- Around line 44-46: The bigint branch in coerceFiniteNumber currently returns
Number(value) which can yield Infinity for very large BigInts; change the bigint
handling to convert to a Number, then validate with Number.isFinite (same
pattern as the number and string branches) and return undefined if not finite so
coerceFiniteNumber preserves its finite-number-or-undefined contract. Ensure you
update the bigint branch inside coerceFiniteNumber to mirror the Number.isFinite
check used for the number and string cases.

In `@packages/db/package.json`:
- Around line 47-50: The package.json lists "@jest/globals": "^30.3.0" while
"jest" is still "^30.1.3" causing a minor-version skew with the lockfile; update
the "jest" dependency in package.json to "^30.3.0" (matching "@jest/globals")
and then regenerate the lockfile (run npm install or yarn install) so the
resolved versions align; target the "jest" entry in package.json to make this
change.

In `@packages/deck/__tests__/compileColorScale.test.ts`:
- Around line 127-162: The tests dereference legend (from buildColorScaleLegend)
without guarding for null even though buildColorScaleLegend returns
ResolvedColorLegend | null; update the tests to handle nullable returns by
either asserting non-null with a `!` when you are certain the input yields a
legend or adding an explicit null check (e.g., expect(legend).not.toBeNull() or
if (legend) { ... }) before accessing legend.type, legend.title,
legend.gradient, legend.ticks, or legend.items so the assertions are type-safe
under strict null checks and clearly reference the buildColorScaleLegend result.

In `@packages/deck/package.json`:
- Line 8: The package.json currently sets "sideEffects": false which causes CSS
side-effect imports used by DeckJsonMap to be dropped; update the package
metadata so CSS is preserved by replacing "sideEffects": false with an array
that includes the CSS files imported by DeckJsonMap (for example a glob like
["**/*.css"] or the exact MapLibre CSS path that DeckJsonMap imports) so
bundlers will retain those side-effectful CSS imports.

In `@packages/deck/src/datasets/normalizeDatasets.ts`:
- Around line 10-27: normalizeDatasetEntry currently treats any non-SQL input as
Arrow, causing invalid objects (e.g., {geometryColumn: 'g'}) to become
{arrowTable: undefined}; update normalizeDatasetEntry to explicitly check
isArrowTableDatasetInput(input) for the Arrow branch and if neither
isSqlDatasetInput(input) nor isArrowTableDatasetInput(input) throw a descriptive
Error (include the dataset id and problematic input) so bad inputs fail loudly;
reference normalizeDatasetEntry, isSqlDatasetInput, and isArrowTableDatasetInput
when making the change.

In `@packages/deck/src/datasets/PreparedDatasetStore.ts`:
- Around line 349-361: The bug is that get().syncConsumer(consumerId, cacheKeys)
runs before ensureEntry creates missing entries so new entries are created with
empty consumers and can be evicted; fix by calling get().ensureEntry(...) for
every descriptor first (use the same descriptors/cacheKey logic in
PreparedDatasetStore where ensureEntry is called) and only after the loop invoke
get().syncConsumer(consumerId, cacheKeys) (or compute cacheKeys from descriptors
and pass them into syncConsumer) so newly-created entries receive the consumerId
and are not considered unreferenced by evictLruEntries.

In `@packages/deck/src/datasets/usePreparedDatasetStates.ts`:
- Around line 36-57: The hook currently depends directly on the datasets record
causing thrashing when callers pass inline objects; modify
usePreparedDatasetStates to derive a stableDatasets reference (e.g., keep a ref
of the previous datasets and perform a shallow equality check on top-level keys
and per-entry identity like sqlQuery/arrowTable) and use that stableDatasets in
the effect dependency list for
preparedDatasetStore.getState().syncDatasetsForConsumer and in the useMemo call
to resolvePreparedDeckDatasetStates; ensure removeConsumer and
syncDatasetsForConsumer still receive consumerId, executeSql and
sqlSourceIdentity (connector) but only re-run when the shallow-stable signature
actually changes.

In `@packages/deck/src/json/layerConfig.ts`:
- Around line 8-22: The two helpers disagree because hasExtensionKeys currently
uses the in-operator and returns true for {_sqlroomsBinding: undefined}; update
hasExtensionKeys to mirror getLayerConfig's criteria by checking that
props._sqlroomsBinding is a non-null object (e.g., typeof
layerProps._sqlroomsBinding === 'object' && layerProps._sqlroomsBinding != null)
so "has extension" only returns true when a usable binding object exists;
reference the hasExtensionKeys and getLayerConfig functions and ensure the same
truthy-object logic is used.

In `@packages/deck/src/prepare/detectGeometryColumn.ts`:
- Around line 53-63: The inferEncodingFromHint function currently drops the
"geoarrow" hint and returns undefined for it; update inferEncodingFromHint to
handle the 'geoarrow' case and return 'geoarrow' so an explicit
geometryEncodingHint is preserved, and make the same change in the other
identical branch referenced (around the second occurrence at lines 110-113) so
both locations return 'geoarrow' when the hint is 'geoarrow' (refer to the
function name inferEncodingFromHint to locate the code).

In `@packages/deck/src/prepare/wkbDecoder.ts`:
- Around line 131-158: supportsGeoArrowPromotion currently only checks the first
non-null geometry via getSampleGeometry which can disagree with
createPromotedPointTable and toGeoArrowLike on mixed-type columns; fix by
extracting a shared validator (e.g., validateAllPointGeometries) used by both
supportsGeoArrowPromotion and the promotion/conversion path
(createPromotedPointTable / toGeoArrowLike) that scans the entire column (or
caches a one-pass result keyed by table+column+encoding) and returns either "all
Point|null" or the offending type, then use that boolean/result in
supportsGeoArrowPromotion to only claim promotion when every non-null row is a
Point and reuse the same validation result during conversion to avoid
mid-pipeline failures.

In `@packages/deck/src/types.ts`:
- Around line 37-40: The union DeckDatasetInput is ambiguous because
DeckArrowTableDatasetInput currently has an optional arrowTable, so objects like
{geometryColumn: 'g'} match neither discriminant and normalizeDatasetEntry can
incorrectly treat them as Arrow entries; fix by making the discriminant
explicit: either change DeckArrowTableDatasetInput.arrowTable to a required
property (e.g., DeckTable | undefined) so the presence/absence is unambiguous,
or add a string discriminant (e.g., kind: 'sql' | 'arrow') to both
DeckSqlDatasetInput and DeckArrowTableDatasetInput and update the type, the
factory/normalizer (normalizeDatasetEntry) and predicates (isSqlDatasetInput,
isArrowTableDatasetInput) to use that discriminant. Ensure all uses of
DeckDatasetInput, isSqlDatasetInput, isArrowTableDatasetInput, and
normalizeDatasetEntry are updated to rely on the chosen discriminant.

---

Outside diff comments:
In `@packages/mosaic/src/MosaicSlice.ts`:
- Around line 189-317: The stored queryResultCallback semantics are
inconsistent: createClient stores a wrapper that converts raw data via
toArrowClientResult before calling the user callback, but ensureClient stores
options.onQueryResult raw, which can lead to callers receiving unconverted data;
update ensureClient so the stored
draft.mosaic.clients[options.id].queryResultCallback is the same wrapped form
used in createClient (i.e., if options.onQueryResult is provided, store a
function that takes the raw result, runs toArrowClientResult(result) and then
calls options.onQueryResult with that ArrowTable), and ensure the
TrackedClient.queryResultCallback type remains (result: ArrowTable) => void.

In `@packages/mosaic/src/useMosaicClient.ts`:
- Around line 55-75: The onQueryResult callback passed into ensureClient is
redundantly calling toArrowClientResult before forwarding the value to
queryResultRef.current even though ensureClient (see MosaicSlice.ensureClient)
already provides an ArrowTable to its callback; remove the extra conversion and
forward the result directly by changing the onQueryResult handler in
useMosaicClient to call queryResultRef.current?.(result) instead of
queryResultRef.current?.(toArrowClientResult(result)), keeping the rest of the
ensureClient call and related symbols (stableId, selectionName, directSelection,
queryRef) intact.

In `@packages/ui/src/theme/theme-provider.tsx`:
- Around line 139-150: The current useIsomorphicLayoutEffect only runs when the
React prop `theme` changes, so when `theme === 'system'` OS color-scheme changes
don't update `resolvedTheme` or the root class; modify the effect that uses
`useIsomorphicLayoutEffect` to, when window is present and `theme === 'system'`,
subscribe to window.matchMedia('(prefers-color-scheme: dark)') change events,
and in the listener re-compute `getResolvedTheme(theme)`, update the
documentElement classes and cause the context value's `resolvedTheme` to update
(e.g., via state or forcing an update), and clean up the listener on unmount;
ensure existing behavior remains for non-'system' themes.

---

Nitpick comments:
In `@examples/deckgl-mosaic/src/components/map/MapView.tsx`:
- Around line 207-222: The deckProps callbacks in MapView use unsafe "any"
coercions (onViewStateChange, onHover, getTooltip) which disables type checking;
replace these with the correct types from `@deck.gl/core`: import and use the
OnViewStateChange callback shape for onViewStateChange (accepting {viewState,
oldViewState?, interactionState?}) and use PickingInfo for the onHover and
getTooltip parameters (e.g., onHover: (info: PickingInfo) => void and
getTooltip: (info: PickingInfo) => string | null), update the signatures in the
deckProps object (references: deckProps, onViewStateChange, onHover, getTooltip)
and remove the "as any" casts so TypeScript enforces correct payload shapes.
- Around line 59-63: The useEffect that calls getSelection('brush') is redundant
because useMosaicClient already ensures the 'brush' selection via ensureClient
and respects connectionStatus; remove the entire useEffect block (the effect
referencing brush and getSelection) to avoid duplicate initialization and the
stale getSelection dependency, and rely on useMosaicClient to create/update the
selection (look for useEffect, getSelection('brush'), useMosaicClient,
ensureClient, and the selectionName 'brush' to locate the code to delete).

In `@packages/color-scales/__tests__/scale.test.ts`:
- Around line 30-52: The tests currently use a conditional guard (if
(legend?.type === ...)) that can hide a missing legend; before branching on
legend.type in both the categorical and quantile/stepped tests, add an explicit
assertion that legend is defined (e.g., expect(legend).toBeDefined()) and then
assert the discriminant (expect(legend.type).toBe('categorical') / 'stepped') so
the subsequent items length checks on buildColorScaleLegend's returned legend
always run; update the two test blocks around the legend variable to remove
optional chaining for the type and items checks after the presence assertion.

In `@packages/color-scales/__tests__/schemas.test.ts`:
- Around line 1-20: Add a negative test to assert ColorScaleConfig rejection for
invalid input: create a new it block that calls ColorScaleConfig.parse (or
safer: use try/catch or zod's safeParse) with an invalid payload (e.g., missing
type or invalid scheme like scheme: 'BadScheme') and assert it throws or returns
an error; reference ColorScaleConfig.parse in the test and mirror the existing
test style used for sequential scales so the suite verifies rejection behavior
as well.

In `@packages/color-scales/jest.config.js`:
- Around line 1-5: Add a JSDoc type annotation above the export to match the
sibling config: place /** `@type` {import('ts-jest').JestConfigWithTsJest} */
immediately before the export default block (which currently spreads
...nodeConfig imported from '@sqlrooms/preset-jest/node.js') so editors get the
same IntelliSense and parity with packages/deck/jest.config.js.

In `@packages/color-scales/src/ColorScaleLegend.tsx`:
- Around line 31-43: The tick alignment currently assumes only offsets 50 and
100 inside the legend.ticks map in ColorScaleLegend.tsx, causing misaligned
labels for other offsets; change the rendering of ticks in the map (where
tick.offset and tick.label are used and className is built) to position labels
absolutely relative to the gradient container using left: `${tick.offset}%` (or
equivalent CSS style) and adjust text alignment (e.g., translateX or text-align)
based on offset to avoid overlap; ensure the gradient container is position:
relative and each tick span is position: absolute so labels align with their
gradient stop instead of relying on justify-between.

In `@packages/color-scales/src/config.ts`:
- Around line 16-28: Refactor RGBAColor to avoid repeating the per-channel
constraint: create a reusable constant (e.g., channel =
z.number().int().min(0).max(255)) and then build RGBAColor using that symbol
(for example z.tuple([channel, channel, channel]).or(z.tuple([channel, channel,
channel, channel])) or a length-aware tuple/rest approach), replacing the
current explicit duplicated numeric constraints inside RGBAColor so future edits
only change the channel definition once.

In `@packages/deck/__tests__/DeckSpec.test.ts`:
- Around line 35-52: The test in DeckSpec.test.ts currently uses a broad
expect(...).toThrow() which can mask unrelated errors; update the assertion on
DeckJsonMapSpec.parse(...) to specifically assert that the rejection is due to
the invalid color scheme (e.g., use expect(() =>
DeckJsonMapSpec.parse(...)).toThrow(/scheme/i) or parse in a try/catch and
assert the ZodError contains an issue with the getFillColor.scheme path),
referencing the DeckJsonMapSpec.parse call and the getFillColor.scheme field so
the test only passes for the intended invalid-scheme error.

In `@packages/deck/src/datasets/helpers.ts`:
- Around line 8-21: Change the standalone declaration and export of
nextAccessTimestamp to an inline exported function (export function
nextAccessTimestamp()) to match the other helpers; leave the module-scoped
counters nextTableIdentity/nextSqlSourceIdentity and WeakMaps
tableIdentities/sqlSourceIdentities as-is for runtime behavior, but update any
tests (e.g., preparedDatasetStore.test.ts) that assert on literal identity
strings like "table:1" to avoid depending on module-level counter values across
Jest workers/HMR (use pattern matching or compare semantic properties instead).

In `@packages/deck/src/datasets/usePreparedDatasetStates.ts`:
- Around line 10-33: The module-global nextPreparedDatasetConsumerId used in
usePreparedDatasetStates can reset across HMR/module re-exec and may collide;
replace the manual counter with a stable id generator already used elsewhere
(e.g., call createId() as used by useMosaicClient or use React.useId()) so each
consumer gets a robust unique id; update the consumer id initialization in
usePreparedDatasetStates to use the chosen id generator instead of incrementing
nextPreparedDatasetConsumerId and remove or deprecate the module-global counter.

In `@packages/deck/src/DeckJsonMapSpec.ts`:
- Around line 7-13: The ColorScaleFunction currently intersects '@@function'
with the discriminated union ColorScaleConfig which prevents Zod's discriminator
fast-path and yields less precise types; to fix, export the individual variant
schemas (e.g., SequentialColorScaleConfig, DivergingColorScaleConfig, etc.) from
`@sqlrooms/color-scales`, then extend each variant with '@@function':
z.literal('colorScale') and reassemble them into a discriminated union before
exporting ColorScaleFunction so the discriminator stays intact and inference
improves (update references to ColorScaleFunction and ColorScaleConfig
accordingly).

In `@packages/deck/src/json/colorScaleFunction.ts`:
- Around line 22-30: isColorScaleMarker currently only checks for the
SQLROOMS_COLOR_SCALE_MARKER symbol, so objects with that symbol but missing or
invalid payload pass; update isColorScaleMarker to also verify the payload by
asserting the object has a colorScale property and that colorScale matches the
expected shape (e.g., non-null object or expected array/structure of
ColorScaleConfig) before returning true. Locate isColorScaleMarker and extend
its Boolean condition to check typeof (value as any).colorScale and/or
Array.isArray((value as any).colorScale) according to the intended
ColorScaleConfig shape; ensure this aligns with how createColorScaleMarker
constructs the marker and how getColorScale casts/uses value.colorScale.

In `@packages/deck/src/json/compileColorScale.ts`:
- Around line 80-127: compileColorScale currently materializes the full column
via getColumnValues(vector) every time and also implements an undocumented
GeoArrow fast-path that reads value.data?.data; to fix this, memoize the
materialized array per unique (table, field) pair (compute once where
getColumn(table, colorScale.field) is called and pass the resulting values array
into both compileColorScale and buildColorScaleLegend instead of calling
getColumnValues twice) and update getGeoArrowOrRowValue to avoid relying on
internal shapes (or at minimum annotate the function with a clear comment citing
the exact `@geoarrow/deck.gl-layers` version and the expected structure being
accessed), referencing the functions getColumn, compileColorScale,
buildColorScaleLegend, getColumnValues, and getGeoArrowOrRowValue so the change
is easy to locate.

In `@packages/deck/src/prepare/toGeoJsonBinary.ts`:
- Around line 15-36: The loop calls table.getChild(fieldName) for every
row×column which is expensive; hoist those lookups by resolving the child
vectors once into an array before iterating rows (e.g. build an array like
children = propertyColumns.map(name => table.getChild(name))) and then inside
the for loop use children[idx]?.get(rowIndex) to populate properties; update
references to
propertyColumns/table.getChild/getGeometryAt/features/table.numRows accordingly
and ensure you handle any undefined children when reading values.

In `@packages/mosaic/src/MosaicColorLegend.tsx`:
- Around line 46-61: The switch in getVgColorScaleType(colorScale:
ColorScaleConfig) is non-exhaustive and can return undefined if a new
ColorScaleKind is added; update the switch to include a default case that does
an exhaustive-never check (e.g., accept a never-typed value or throw with a
clear message) so the compiler will error for unknown ColorScale kinds and avoid
passing undefined into vg.colorScale; reference getVgColorScaleType and
ColorScaleConfig (and the ColorScaleKind union) when applying the fix.

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

Inline comments:
In `@packages/color-scales/src/scale.ts`:
- Around line 166-188: Replace the spread-based Math.min/Math.max calls in
getSequentialDomain and getDivergingDomain with an explicit loop-based extent
calculation to avoid argument-limit RangeErrors: iterate over the values array
to compute min and max (e.g., initialize min = Infinity, max = -Infinity and
update in a for loop), then reuse the existing branch logic in
getSequentialDomain and getDivergingDomain (including the equal-value and
diverging-zero handling) and return the same typed tuples.

In `@packages/deck/src/datasets/helpers.ts`:
- Around line 58-102: The cache key builder (resolvePreparedDatasetCacheKey and
buildGeometryKey) currently joins parts with '\u0001', which can collide when
parts contain that delimiter; change it to produce a structured, collision-safe
key by encoding parts as a JSON array or using length-prefixed concatenation
instead of a simple join. Update resolvePreparedDatasetCacheKey to serialize the
array ['sql'|'arrow', getSqlSourceIdentity(sqlSourceIdentity) or
getTableIdentity(table), input.sqlQuery (for SQL) or omitted, and
buildGeometryKey(input)] with JSON.stringify (or equivalent stable encoder) and
ensure buildGeometryKey returns a structured object or tuple (e.g., {column,
encodingHint}) that is included in the serialized key so distinct inputs cannot
collide. Ensure thrown error behavior in resolvePreparedDatasetCacheKey remains
unchanged and callers still expect a string | undefined.
- Around line 80-92: The cache key for SQL datasets omits data-revision info, so
include the optional version in the key and propagate it through the call chain:
update resolvePreparedDatasetCacheKey (the function containing the shown branch)
to accept a version (or include version from sqlSourceIdentity) and append it to
the returned join alongside 'sql', getSqlSourceIdentity(sqlSourceIdentity),
input.sqlQuery and buildGeometryKey(input); then update callers
(usePreparedDatasetStates and any ensureEntry/executeSql invocations) to pass
the same version through to resolvePreparedDatasetCacheKey and to executeSql so
prepared entries are invalidated when version changes.

In `@packages/deck/src/datasets/normalizeDatasets.ts`:
- Around line 45-52: normalizeDatasets currently throws synchronously on an
empty datasets record which can crash component renders; document the contract
and prevent unexpected throws by (1) adding a clear JSDoc to normalizeDatasets
describing that it throws when passed an empty record (mentioning the error
message) and (2) adding a guard at the caller (e.g., DeckJsonMap or its loader)
to check datasets is non-empty before calling normalizeDatasets (or handle the
empty case with a no-op render), referencing the normalizeDatasets function and
the DeckJsonMap consumer to locate where to apply the guard.

In `@packages/deck/src/prepare/wkbDecoder.ts`:
- Around line 37-48: The handler currently routes all non-WKT encodings to WKB
parsing, which breaks when encoding === 'unknown'; update parseGeometryValue to
treat encoding === 'unknown' specially by type-checking the incoming value: if
encoding === 'wkt' || encoding === 'geoarrow.wkt' || (encoding === 'unknown' &&
typeof value === 'string') call WKTLoader.parseTextSync with {wkt:{crs:false}},
otherwise (encoding === 'unknown' with non-string or other binary encodings)
call WKBLoader.parseSync with toArrayBuffer(value) and
{wkb:{shape:'geojson-geometry'}}; apply the same change to the similar branch in
tryPromotePointTable so string unknowns go to WKT parsing and binaries go to WKB
parsing.
- Around line 96-113: The loop that builds points for promotion must normalize
and validate coordinates: when reading geometry via parseGeometryValue (and
using geometry.coordinates), ensure you extract only the first two elements [x,
y] (drop z/m) and verify both are finite numbers (Number.isFinite) before
pushing into points; if the geometry is non-Point, has missing coords, or
contains non-finite values, push null (or return null only where appropriate) so
that vectorFromArray(promotedGeometry, geomType) receives only 2D finite
coordinate pairs or nulls; update the loop around parseGeometryValue, points,
and the FixedSizeList(2) promotion to perform this normalization and validation
prior to calling vectorFromArray.

In `@packages/mosaic/src/MosaicSlice.ts`:
- Around line 54-62: ensureClient currently treats an existing TrackedClient as
up-to-date by only comparing selection, which allows new query, onQueryResult,
or queryResult values to be ignored and produce stale bindings; update
ensureClient to compare and track the identities of query, onQueryResult, and
queryResultCallback (in addition to selection) on the stored TrackedClient and
recreate or rewrap the client when any of those identities differ, or
alternatively store both raw callback identities and the wrapped callback it
passes into makeClient so you can update the wrapped function when the external
callback changes; focus your changes in the ensureClient function and the
TrackedClient shape to add fields for query identity and external callback
identities and use those to decide when to re-create or update the
client/wrapped callbacks.

---

Nitpick comments:
In `@examples/deckgl-mosaic/src/components/map/MapView.tsx`:
- Around line 206-214: In getTooltip, sanitize and format numeric fields and
guard against missing/odd values: ensure Number(object.Magnitude) is checked (or
fallback to null/empty) before calling toFixed(1) and render a fallback like "M
—" when not a valid number; format object.Depth to a fixed number of decimals
(e.g., toFixed(1) or rounded) only if it is numeric and append "km", otherwise
show a safe fallback like "Depth —"; also ensure dateLabel is coerced to string
safely (e.g., default to empty string) so the tooltip never shows "NaN" or
"undefined" for the fields referenced in getTooltip.

In `@packages/mosaic/src/MosaicSlice.ts`:
- Around line 367-397: The JSDoc above createDuckDbMosaicConnector is out of
date: update the doc to describe that Arrow queries are converted by calling
createMosaicTableFromArrowTable on the Arrow Table returned by DuckDbConnector
(instead of describing the old IPC bytes/decodeIPC path), and remove references
to decodeIPC/IPC serialization; keep notes about JSON path using Array.from and
the intentional as any adapter casts, and reference DuckDbConnector, Connector,
and the query methods in the updated wording.