feat: SQL Server 2025 support (plus as_columnstore docs and a store-failures regression test)

[joshmarkovic]

Summary

This branch bundles three independent changes. Happy to split into separate PRs if that is easier to review.

1. SQL Server 2025 support (703862b)

• Cover SQL Server 2025 in the integration-test matrix (pyodbc and mssql-python on Python 3.13 / ODBC Driver 18) and add it to the published server CI images.
• Rename the server.Dockerfile build arg SQLServer_VERSION to MSSQL_VERSION so it matches the build-arg the workflow already passes. With the old name the matrix value was ignored and every server-* image was built from the 2022 default, so the 2017/2019 (and now 2025) images were silently all 2022.
• Document 2025 as a supported version and refresh the stale dbt-core compatibility note (0.14 to 1.10).

2. Document the as_columnstore config (391080c, refs #440)

The as_columnstore config (default true, which builds a clustered columnstore index) was undocumented. This adds a README section, including the workaround for test failure storage: audit tables can contain (n)varchar(max) columns, which SQL Server does not allow in a columnstore index, so as_columnstore: false on those resources avoids the build error.

3. Regression test for store-failures on passing tests (7d8e90b, refs #601)

A passing test run with --store-failures should leave an empty audit table, not drop it (the documented dbt behavior, and what Postgres does). This adds a functional test asserting the audit relation persists as an empty user table across idempotent re-runs.

This closes a coverage gap: the existing test_store_test_failures.py suite only asserted the passing case for view-based store-failures, never the table-based case from #601.

Verified locally against SQL Server 2022 with a case-sensitive collation: the new test passes, and the existing 6-test store-failures suite still passes. The reported behavior no longer reproduces on current master, so the test serves as a regression guard.

[joshmarkovic]

The only failing job was the SQL Server 2017 leg, and it was exposed (not caused) by this PR.

Root cause: before this PR, devops/server.Dockerfile declared ARG SQLServer_VERSION while publish-docker.yml builds the images with build-args: MSSQL_VERSION=.... The names didn't match, so Docker silently ignored the build arg and every server-20xx image was built FROM mcr.microsoft.com/mssql/server:2022-latest. In other words, CI's "2017" leg has never actually run SQL Server 2017.

Proof that the old "2017" tests ran on a 2022 engine: master's most recent SQL2017 job reports Microsoft SQL Server 2022 (RTM-CU25) ... 16.0.4255.1, see run 28142611656, the SQL2017 job (search the log for Microsoft SQL Server). After this PR corrects the arg name and the images were rebuilt, the 2017 leg finally runs a genuine 2017 (14.0.3530.2), see the failing job on this PR.

On a real 2017 engine, two existing index tests failed because the create-index macro emitted options that only SQL Server 2019+ recognizes:

• test_full_option_surface → 'optimize_for_sequential_key' is not a recognized CREATE INDEX option (155)
• test_table_create_path_post_commit → 'resumable' is not a recognized CREATE INDEX option (155)

Fix (pushed): we support 2017 (Microsoft still does), so I gated those options on the detected engine major version. On versions below 2019 (major < 15), optimize_for_sequential_key, resumable and resumable's max_duration are dropped (with a warning) and the index is built without them instead of failing. ONLINE is kept (it's recognized on 2017; it's edition-gated, not version-gated). Behavior on 2019+ is unchanged, and both tests now pass on 2017 with no test changes.

@axellpadilla flagging for visibility.