feat(java)!: native text[]/uuid[] OMDB binding + text default; drop uuid_array/text_array dbColumnType (phase 1)

[dmealing]

Part of dbColumnType slim-and-derive Phase 1 (Java port). Applies the project's own ADR-0023 principle to the @dbColumnType escape hatch: native array columns and the no-maxLength text default are now derived from field.subType + isArray + maxLength, not declared.

Spec: docs/superpowers/specs/2026-06-29-dbcolumntype-slim-and-derive-design.md (on feat/dbcolumntype-slim-derive).

What changed

1. Vocabulary slim (shared JVM value-set)

CoreDBMetaDataProvider.VALID_DB_COLUMN_TYPES drops uuid_array / text_array (+ the ValidationPhase legal-pairing table). Kept: uuid, jsonb, timestamp_with_tz. A no-maxLength field.string already defaults to a text column, so the vestigial text value was never in the Java value-set. uuid_array / text_array / text on @dbColumnType now fail the loader with ERR_BAD_ATTR_VALUE.

2. NEW OMDB native array binding

OMDB previously had no text[] / uuid[] JDBC support. Built it:

• New per-driver nativeArrayElementType() hook: base GenericSQLDriver returns null (no native arrays — Derby et al. fall through to the scalar codec); PostgresDriver overrides → "text" for field.string isArray, "uuid" for field.uuid isArray. The element type is derived from the field subtype (the removed declared values).
• Write: bindNativeArrayParameter() → Connection.createArrayOf(...) + setArray. uuid[] elements bind as java.util.UUID.
• Read: readNativeArrayInto() → ResultSet.getArray. uuid[] elements read back lowercase-canonical (cross-port wire contract, dialect-independent).
• Root-cause fix in MetaField: getObjectValue / setObjectAttribute were scalar-typed (getValueClass() / dataType), which comma-joined an array field's List into a String. Now use the array-aware getEffectiveValueClass() / getEffectiveDataType() — for a scalar field these equal the base class/type, so non-array behavior is byte-unchanged (proven by the full suites below).

3. field.string default → text

SimpleMappingHandlerDB.readStringMaxLength no longer hardcodes VARCHAR(50) for a no-maxLength string; it returns an UNBOUNDED_TEXT_LENGTH sentinel aligned with the canonical TS-owned text column. OMDB does no DDL (ADR-0015), so the runtime string bind was already unbounded — this corrects ColumnDef metadata only.

4. DTO

field.uuid isArray → List<java.util.UUID>, field.string isArray → List<String> (already wired via SpringDtoGenerator.componentType; pinned by new SpringTypeMapperTest cases — the spec's "uuid isArray DTO throws" was already resolved for the DTO path).

Timestamp behavior untouched (Phase 2).

Test evidence

TDD. New tests:

• DbColumnTypeValidationTest — uuid_array / text_array / text → ERR_BAD_ATTR_VALUE.
• SpringTypeMapperTest — string/uuid isArray DTO components.
• NativeArrayWriteRoundtripTest (integration-tests) — Testcontainers Postgres ran (Docker available): INSERTs a text[] and a uuid[] through ObjectManagerDB.createObject (NOT raw SQL), reads back, asserts the Lists round-trip (uuid lowercase-canonical). Green against real PG.

Suites green: metadata 1058, omdb 46, codegen-spring 148, integration-tests 86 (full suite, incl. all persistence conformance — the core MetaField change caused zero regressions).

Java/Kotlin shared-file coordination ⚠️

CoreDBMetaDataProvider's value-set is shared with the Kotlin port. This PR removes the uuid_array / text_array constants there. KotlinTypeMapper.kt still references them and is converted to the derived default by the parallel Kotlin port change — the two PRs merge together. codegen-kotlin is not in this PR's tested reactor (metadata,omdb,codegen-spring), which builds and tests clean.

Part of dbColumnType slim-and-derive Phase 1

🤖 Generated with Claude Code

[dmealing]

Folded into the integrated Phase-1 PR (feat/dbcolumntype-slim-derive) which merges all five ports atomically — that's the one that lands. Keeping this open for per-port review history.

[dmealing]

Landed via the integrated Phase-1 PR #121 (squash-merged to main).