refactor(isthmus): derive CREATE-statement table types from the provider

[nielspardon]

Summary

Finishes the deferred half of @vbarua's comment on #1035 —
"I wonder if it would make sense to get the RelTypeFactory and SqlConverterBase from the
ConverterProvider as well". #1036 threaded the provider into the CalciteCatalogReader
construction; this covers the type derivation underneath it.

The gap

On the provider-injected path (processCreateStatementsToCatalog(provider, …) →
processCreateStatementsToSchema(provider, …) → createSubstraitTable(…)):

• createSubstraitTable built the row type with SubstraitTypeSystem.TYPE_FACTORY, not the
  provider's type factory.
• Column types came from col.dataType.deriveType(VALIDATOR), where VALIDATOR and
  EMPTY_CATALOG are static final, built on the global type factory plus
  SqlConverterBase.CONNECTION_CONFIG.

So a builder-configured typeFactory produced a catalog reader that used it while the tables
inside were typed by the global one. That is harmless today — getCalciteConnectionConfig()
returns the same case-insensitive config as SqlConverterBase.CONNECTION_CONFIG — but a custom
type factory carrying a different type system (different decimal precision limits, say) was
silently bypassed for table column types.

Changes

• New private createEmptyCatalog(ConverterProvider) and createValidator(ConverterProvider)
  helpers. Because SubstraitSqlValidator takes its type factory from the catalog reader, fixing
  the empty catalog fixes column derivation as well.
• The validator is built once per call and passed, with the provider's type factory, into
  createSubstraitTable.
• EMPTY_CATALOG and VALIDATOR are kept and now defined via the same helpers against
  ConverterProvider.DEFAULT, so their values are unchanged and nothing public was removed.

Note on scope

Two things worth calling out explicitly, both easy to drop if you would rather they were separate:

1. The validator is now built with converterProvider.getSqlOperatorTable() instead of a
   hardcoded SubstraitOperatorTable.INSTANCE, matching how feat(isthmus)!: inject ConverterProvider into the SQL statement parsers #1035 made the query path source its
   operator table. Identical for the default provider; it only matters for a provider that adds
   operators.
2. EMPTY_CATALOG and VALIDATOR now have no callers inside the class either (each entry point
   derives its own from the provider). They are still public, so they are retained — but if you
   want them deprecated in favour of the provider-derived path, that is a one-line follow-up.

Independent of #1037 — no overlapping files, so the two can merge in either order.

🤖 Generated with AI

[bvolpato]

Nice targeted coverage around both entry points. Non-blocking test thought: Calcite uses a static interner here, so canonizing a field type cannot distinguish the provider factory from the global factory. Recording createSqlType calls on RecordingTypeFactory, or asserting a custom type-system result, would make this check protect the validator path too.

[bvolpato]

LGTM! Clean provider-config propagation through CREATE parsing, with focused coverage for both entry points and defaults. Left one non-blocking test-strengthening note inline.