One JDBC type catalogue, in core, that both transports derive from (BIDC-10a)

[fupelaqu]

Follow-on to #320, same story. One JDBC type catalogue, in core, that both transports derive from.

Why

DatabaseMetaData.getTypeInfo in softclient4es-jdbc and XdbcTypeInfoRows in softclient4es-arrow were
two independent hand-written transcriptions of a mapping that already existed in the driver
(TypeMapping.toJdbcType). Nothing forced either list to track that mapping, so both drifted.

That is the same defect #320 fixed one layer down: two places encoding one fact. Here it had three
consequences, and the third is the one that matters.

1. Both lists were incomplete — 11 rows.
2. Both inherited a row order that violates the getTypeInfo javadoc (rows must be ordered by
   DATA_TYPE); it was fixed by hand in both repos, which is exactly the fragility being removed.
3. 🔴 getColumns.TYPE_NAME reports the ENGINE's type id, so a character column comes back as
   KEYWORD or TEXT, never VARCHAR. At 11 rows, KEYWORD, TEXT, DATETIME, CHAR, STRUCT,
   GEO_POINT, VARBINARY and ARRAY<…> round-tripped to no catalogue row at all. Neither
   transcription could reveal it, because each was self-consistent with itself.

What this adds

core/.../client/metadata/JdbcTypeCatalog.scala — 20 rows plus find(typeId) to resolve a
getColumns type name back to its row.

It lives in core, not sql: the AST and parser module gains no java.sql dependency, and both
drivers already compile against core. That is what turns the cross-repo agreement from a convention
into a real interlock — previously, adding a row to one repo left the other's build green.

Derived, not stated. A row carries a SQLType; its typeId and DATA_TYPE are computed from
sqlType.typeId and the single jdbcType mapping. A row and the mapping cannot disagree by
construction.

All eleven pre-existing rows are byte-identical. The nine new sizes follow a rule rather than being
invented per type: types sharing a DATA_TYPE share its precision (NUMERIC 15, DATETIME 23,
TEXT/KEYWORD/GEO_POINT 65535); CHAR and VARBINARY have their own codes and no engine bound, so
they take the same ceiling; STRUCT and ARRAY have none.

NULL is excluded, with the reason in source. getTypeInfo describes types a column can have;
Types.NULL is the absence of a value, not a storable type, and no mainstream driver lists it. Its
presence in the SQLType → code mapping is legitimate and different — that maps an inferred runtime
type.

⚠️ The ordering contract changes, and downstream assertions must move

At 11 rows every DATA_TYPE was distinct, so the javadoc's tie-break never applied and both repos
asserted "sorted and distinct". At 20 rows, four types share Types.VARCHAR, two share DOUBLE
and two share TIMESTAMP. Distinctness is gone, and any surviving distinctness assertion is
pinning the old catalogue.

The tie-break is computed, not enumerated: the canonical JDBC name for a code sorts first
(JDBCType.valueOf(dataType).getName == typeId, which is the javadoc's "how closely the data type maps
to the corresponding JDBC SQL type"), then typeId ascending for totality. Hand-listing an order would
have been a fourth place encoding one fact.

Falsified three ways; the decisive one is that shuffling the declaration changes nothing, which no
positional fixture can prove.

Verification

core/test 967/967 · + core/compile · ++ 2.12.20 core/Test/compile · headerCheck,
scalafmtSbtCheck, scalafmtCheck, test:scalafmtCheck. Published locally and content-verified with
javap on the jar, not a directory listing.

Downstream

Both drivers repin to 0.23.0-SNAPSHOT and derive from this object; their branches are held pending
this merge and a publish, since a shared object is invisible from a pinned released core.

Second commit — one deep Scala-to-Java value conversion, at the consumer boundary

core/.../client/metadata/JavaValueConversion.toJavaValue turns Scala Map/Seq/Set into
java.util.LinkedHashMap/ArrayList/LinkedHashSet, recursively on both keys and values.
LinkedHashMap because core's maps are ListMaps whose key order is meaningful to a consumer walking
a struct. byte[] is untouched — a Java array is not a Scala Seq, and a java.util.List[Byte] breaks
every [B cast. Non-collections return the same reference: one type test, zero allocation.

It exists because toJdbcClassName reports STRUCT as java.lang.String (a catch-all fall-through)
and ARRAY as java.sql.Array, which the driver never constructs — createArrayOf and createStruct
both throw. Those repairs are the drivers'; this is the seam they need.

🔴 A census done while building it changed its design, and is the reusable part. jsonNodeToAny is
not the only producer of these shapes. Three are, and only one goes through it:

1. jsonNodeToAny — array → Scala List, object → ListMap.
2. the aggregation path — a stats aggregation emits name -> ListMap("count" -> …, "sum" -> …),
   percentiles emits name -> ListMap(key -> double); both as cell values, neither from a JsonNode.
3. extractInnerHits — innerHitName -> List[ListMap[String, Any]], hand-assembled, and precisely
   the List-of-Map shape a shallow conversion gets wrong.

A producer-side converter would have been honest for one path and a lie for two. It sits at the
consumer boundary instead, producer-agnostic by construction — a fourth producer needs no change.
Before centralising a conversion, census the producers; the obvious answer is rarely the complete one.

Lazy at the accessor, not eager per row. Eager conversion would allocate on the extraction path for
every row of every query, including the majority with no collection cell and no getObject call — the
path #238 and arrow#139 exist to keep cheap. Not memoised here, because core does not own the row's
lifetime; a driver that measures repeated access to one wide struct can cache at its own seam.

🔴 The shallow implementation passed 7 of 11 tests — written deliberately first. It passed every
single-level case, key order, reference identity, null, byte arrays and empty collections, failing only
the four depth-sensitive ones. A conversion suite without a nested-inside-array case cannot tell deep
from shallow, and shallow is what a reviewer's eye reads as correct. One test drives real core code
(jsonNodeToAny on an array of objects) and asserts both halves, so if a producer ever starts emitting
Java collections that test says so rather than toJavaValue silently becoming dead code.

No issue is filed for this story, per the epic's issue-lifecycle rule, so this PR carries no closing
keyword.

🤖 Generated with Claude Code