release: 0.2.2 — raise Hotdata SDK ceilings

[eddietejeda]

Summary

• Raise SDK ceilings to hotdata>=0.8.0,<0.10 and hotdata-framework>=0.9.0,<0.15, letting consumers resolve the newest coherent pair — currently hotdata 0.9.1 + framework 0.14.0 (framework releases declare their own compatible hotdata range, so the resolver stays coherent within these bounds)
• Lock upgraded to that pair; version bumped to 0.2.2 with a CHANGELOG entry (plus a retroactive 0.2.1 entry)

Testing

With hotdata 0.9.1 + hotdata-framework 0.14.0:

• pytest: 75 passed
• ruff check / ruff format --check / mypy: clean
• Live-workspace validation (yesterday, 0.9.0+0.14.0 force-installed; today re-run via data-engineering follow-up): full dbt run 6/6 and test 12/12 against a real instant database

After merge: tag v0.2.2 to publish to PyPI.

[claude]

nit: add a CI job that runs uv sync --resolution lowest-direct before pytest. The extra job keeps the wide range intact and exercises the floors.

.github/workflows/ci.yml:20 runs plain uv sync against uv.lock, so CI tests only hotdata 0.9.1 + framework 0.14.0. Before this change the lock sat on framework 0.9.0, which equalled the declared floor. After this change the declared floors, hotdata 0.8.0 and framework 0.9.0, stay unexercised across five framework minors.

Failure scenario: a later commit calls an API added in framework 0.11. CI stays green on 0.14.0. A consumer whose environment caps hotdata-framework at 0.9.x installs dbt-hotdata, and the adapter raises ImportError or AttributeError on the first model. (not blocking)

[claude]

super nit: add a test asserting this version string equals the pyproject.toml version. No check ties the two strings today, and .github/workflows/release.yml:15-22 compares the git tag against pyproject.toml only. A future bump that misses this file publishes a wheel where dbt --version reports a stale adapter version. (not blocking)