Add configurable native JSON column type to the loader

[johngrimes]

Adds an optional native JSON column type to the NDJSON loader, letting the resources table store its json column using SQL Server 2025's native JSON type instead of the default NVARCHAR(MAX).

The loader and the load CLI gain a resourceJsonDataType option accepting NVARCHAR(MAX) (default) or JSON. Omitting it leaves existing behaviour unchanged. The value is validated against a strict allowlist before any database connection is opened, and a mismatch against an existing table's column type emits a warning rather than altering the table.

The exists() and empty() FHIRPath translations previously detected an empty array by comparing the extracted value against the literal '[]'. That works over NVARCHAR(MAX), but over the native JSON column JSON_QUERY returns a json-typed value and the comparison raises "the data types json and varchar are incompatible". The compared operand is now wrapped in CAST(... AS NVARCHAR(MAX)) at each array emptiness site, which is a no-op over NVARCHAR(MAX) and makes the generated SQL valid over both column types.

Conformance is proven against the native type: the Vitest harness reads MSSQL_RESOURCE_JSON_DATA_TYPE, and the CI matrix gains a 2025-latest dimension that runs the full suite over both column types while 2017, 2019 and 2022 stay on NVARCHAR(MAX). Documentation covers the new option, the SQL Server 2025 requirement, and a repeatable manual storage and timing benchmark procedure.

Unfortunately it doesn't seem to improve performance over the string column - if anything the performance is worse. But it may be useful for some users, as you can create indexes on JSON columns, which could be useful for some types of queries.

[piotrszul]

Looks good, here is minor suggestion:

resolveColumnJsonDataType silently accepts non-compliant existing column types (src/loader/tables.ts:73)

This classifier maps data_type === 'json' → JSON and everything else → NVARCHAR(MAX):

return dataType.trim().toLowerCase() === "json" ? "JSON" : "NVARCHAR(MAX)";

The consequence is that an existing table whose json column is actually something incompatible — e.g. VARCHAR(100), NVARCHAR(64), TEXT — gets classified as NVARCHAR(MAX). So the mismatch check sees no mismatch (under the default request) and the loader proceeds to write FHIR resources into a column that can't hold them. At load time that surfaces as truncation / String or binary data would be truncated errors, or — worse, under non-Unicode VARCHAR — silent character corruption. The one safeguard we have for existing tables (FR-008) is blind to exactly the cases that actually lose data.

Related: the _characterMaximumLength parameter is fetched by getExistingJsonColumnType and passed in here, but never read — it's the field that would let us tell NVARCHAR(MAX) (length -1) from a bounded NVARCHAR(64), so the information needed to detect this is already on hand.

Suggestion: rather than coercing unknown types into NVARCHAR(MAX), fail fast — if an existing column is neither native JSON nor NVARCHAR(MAX), raise a clear error naming the offending type (e.g. "existing column [json] is VARCHAR(100); expected NVARCHAR(MAX) or JSON") before any rows are loaded. That turns a late, data-dependent truncation failure into an early, actionable configuration error, in keeping with Principle IV (reject invalid input at the boundary with a meaningful message).