refactor(isthmus): decide the fate of SubstraitCreateStatementParser.EMPTY_CATALOG / VALIDATOR

[nielspardon]

Context

#1050 made the CREATE-statement parser derive its type factory, connection config and validator from
the injected ConverterProvider, via private createEmptyCatalog(ConverterProvider) /
createValidator(ConverterProvider) helpers. Each entry point now builds its own from the provider.

As a side effect, the two public constants in SubstraitCreateStatementParser no longer have a
single caller anywhere in the repository — not even inside their own class:

public static final CalciteCatalogReader EMPTY_CATALOG = createEmptyCatalog(ConverterProvider.DEFAULT);
public static final SqlValidator VALIDATOR = createValidator(ConverterProvider.DEFAULT);

They were retained in #1050 purely because they are public and removing them would be a breaking
change. This issue is to decide what they should be.

Why it's worth revisiting

• They are hard-wired to ConverterProvider.DEFAULT, so they sit outside the configuration model
  the rest of the class now follows. A caller with a configured provider who reaches for
  VALIDATOR gets global defaults, which is exactly the inconsistency refactor(isthmus): derive CREATE-statement table types from the provider #1050 set out to remove.
• They are static final, so merely loading SubstraitCreateStatementParser eagerly forces
  ConverterProvider.DEFAULT and builds a catalog reader plus a validator that nothing uses. Worth
  a look at whether that interacts badly with the GraalVM native image build, though I have not
  measured it.

The complication

There is no public replacement to point a deprecation at: the provider-derived helpers are private.
So "just deprecate them" leaves users of the constants with nowhere to go.

Options

1. Leave as is. Cheapest. Keeps a documented default for anyone validating CREATE statements
   outside the parser, at the cost of the inconsistency above.
2. Deprecate and make the helpers public. Gives a migration target
   (createEmptyCatalog(provider) / createValidator(provider)), but widens the public API of a
   class whose surface we have otherwise been narrowing.
3. Deprecate with no replacement, on the grounds that the supported path is the
   processCreateStatements* entry points and nobody should need the raw validator. Remove in the
   next breaking release.
4. Remove outright as part of a batch of breaking changes.

No strong preference from me; (3) looks closest to the intent, but it depends on whether anyone
downstream is actually using these. Low priority either way — behaviour is correct today.