Audit type name translation handling (follow up from #94)

One plausible follow-up gap (not a bug in this PR, latent pre-existing issue in same neighborhood):

The fix only patches TYPE_LABELS/translate_type (the contract-enforcement path). But the base Column class's other type logic — is_string(), data_type, string_type(), can_expand_to() — is still untouched and still assumes Postgres-style type names. is_string() matches on "character varying", "varchar", etc. Flink's information-schema often reports string columns as VARCHAR(n) (e.g. VARCHAR(2147483647)), so is_string() returns True and data_type renders "character varying(2147483647)" — invalid Flink SQL, same failure class as this PR fixes, different entry point. It's reachable via dbt/include/confluent/macros/materializations/tests/unit.sql:62, which calls column.data_type on columns introspected live from Flink (get_columns_in_relation → Column.from_description).

Recommend filing a separate follow-up issue for the is_string/string_type/can_expand_to gap rather than blocking this PR on it — different trigger path (live-catalog introspection vs. contract YAML), so it's reasonable to fix separately.

_Originally posted by @jlrobins in https://github.com/confluentinc/dbt-confluent/pull/94#pullrequestreview-5045656869_

Start with the base Column class methods is_string(), data_type, string_type(), and can_expand_to(), then trace the live-catalog path from get_columns_in_relation through Column.from_description. The issue identifies dbt/include/confluent/macros/materializations/tests/unit.sql:62 as an entry point; done means Flink VARCHAR(n) columns no longer render as invalid Flink SQL.

Written by the indexing model from the issue text.