fix: return True from has_dbr_capability parse stub on SQL warehouses (#1331)

[sd-db]

Motivated by #1331.

The class-level @available.parse(lambda *a, **k: False) stub on has_dbr_capability returns a constant False at parse time, so every macro branching on a capability takes the legacy path during parse/compile — even on SQL warehouses, which support all capabilities we currently ship.

This is a 1.11.0 regression: the pre-1.11 stub (compare_dbr_version) returned 0, and 0 >= 0 accidentally selected the modern path.

Fix

Shadow _parse_replacements_ at adapter __init__ with a bound method that consults the profile's http_path:

• SQL warehouse → True for capabilities with sql_warehouse_supported=True.
• Cluster → False (real DBR version is only known at runtime).

Cluster users on supported DBR are still affected — fully fixing that requires a larger change. This PR is the contained warehouse-only fix.

Test plan

• hatch run pytest tests/unit/test_adapter_capabilities.py -v — 19 pass (4 new).
• hatch run pre-commit run --all-files — clean.
• CI functional run.

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
dbt/adapters/databricks
impl.py
Project Total

This report was generated by python-coverage-comment-action

[nicor88]

@sd-db you can consider to add real functional tests in which for example a date-spine function from dbt-utils is used to check if everything actually works fine with a real warehouse, alternatively something artifically created like date-spine to test a real scenario. The unit tests cover some relevant aspects, but proper integration testings allows to spot regressions in a more solid way.

[sd-db]

@sd-db you can consider to add real functional tests in which for example a date-spine function from dbt-utils is used to check if everything actually works fine with a real warehouse, alternatively something artifically created like date-spine to test a real scenario. The unit tests cover some relevant aspects, but proper integration testings allows to spot regressions in a more solid way.

Good call — added a functional test in tests/functional/adapter/utils/test_dateadd_uppercase.py (commit d6fe3dd).