fix: preserve parameterized physicalType in SQL type converter

[barry0451]

Problem

When an ODCS SchemaProperty has a physicalType with precision or length constraints (e.g. VARCHAR(255), DECIMAL(10,2)), the SQL type converter ignores the constraints and returns the wrong type or None.

Root cause: The per-server converters match bare type names like ["string", "varchar", "text"]. A physicalType of "VARCHAR(255)" doesn't match "varchar", so the converter falls through and returns None.

Fix

Added an early return in convert_to_sql_type(): if the ODCS physicalType already contains parentheses, it is returned verbatim before any server-specific converter runs.

Also adds _extract_base_type() helper (strips params from a type string) for future use.

Tests

63 parametrized tests covering:

• VARCHAR(255), DECIMAL(10,2), NUMERIC(18,4), CHAR(10), NVARCHAR(500), FLOAT(24) across all 8 server types
• Regression tests confirming bare types still route through server-specific converters correctly

Fixes #1086

Co-authored-by: Garrett Sutula 11978161+garrettsutula@users.noreply.github.com

[jschoedl]

Some kind of platform-dependent code is still needed to check if the parametrized types are actually supported. If the physicalType is set to, e.g., NVARCHAR(50), exporting to Postgres would not work (Postgres has no NVARCHAR type).

[barry0451]

Thanks for the feedback — good catch.

The naive verbatim pass-through is replaced with proper server-aware translation:

1. Strip parameters from the physicalType (e.g. NVARCHAR(50) → base=NVARCHAR, params=50)
2. Run the base type through the server-specific converter
3. Re-attach params only if the translated type accepts them on that server (via a _TYPES_ACCEPTING_PARAMS per-server mapping)

Examples of the new behaviour:

• NVARCHAR(50) on Postgres → converter returns None for unknown base type → fallback verbatim NVARCHAR(50) (Postgres will reject this cleanly rather than silently producing wrong SQL)
• VARCHAR(255) on Postgres → base varchar → text, text doesn't accept params → text
• DECIMAL(10,2) on Postgres → base decimal → decimal, accepts params → decimal(10,2)
• VARCHAR(255) on Snowflake → base varchar → VARCHAR, accepts params → VARCHAR(255)

21 new tests cover helpers and cross-server translation cases.

[jschoedl]

Thanks, LGTM! I refined the listing of parametrizable types a bit. I think that NVARCHAR should actually be mapped to TEXT in the postgres case, and sql_type_converter could soon deserve a rewrite - but those are out of scope for this PR.