Lock in that cursor.description's type_code is the Flink type name string

Statement.description
(statement.py:463) returns col.type.type as the PEP-249 type_code field, which is exactly
the same Flink type name string ("INTEGER", "ROW", "ARRAY", etc.) used as the keys in the
type-converter table from item #3. That's a genuinely convenient alignment: a SQLAlchemy
dialect's reflection/result-typing code can key directly off cursor.description[i][1] using the
same vocabulary as #3's public type table, with no translation layer in between.

There's no such contract documented today, though — it's true by coincidence of both pieces of
code reading ColumnTypeDefinition.type. Worth: (a) a one-line docstring note on
Statement.description stating this equivalence explicitly, and (b) a small regression test
asserting description's type codes are always a subset of the type-converter table's keys, so
this doesn't silently drift apart later (e.g. if type_code were ever changed to report something
else, like a Python type or a display string, without anyone realizing a downstream consumer
depended on the current string).