chore: release hotdata-runtime v0.2.1

[eddietejeda]

Summary

Release hotdata-runtime v0.2.1.

Checklist

• Version bumped in pyproject.toml
• CHANGELOG.md updated
• CI green

After merge, run ./scripts/release.sh publish from a clean main checkout.

[claude]

This changelog entry is the update_changelog.py fallback boilerplate that gets emitted when [Unreleased] is empty (see scripts/update_changelog.py:21-25). But there is a real, user-visible change in this release: commit 629b018 (feat: add database parameter to execute_sql for managed database scoping, #11) added an optional keyword-only database parameter to execute_sql that resolves to a managed database ID and is sent as the X-Database-Id header. That is exactly the kind of API addition consumers reading the changelog need to know about.

Please replace the placeholder with a description of what actually shipped, e.g.:

Suggested change

	## [0.2.1] - 2026-05-24
	### Changed
	- Release 0.2.1
	## [0.2.1] - 2026-05-24
	### Added
	- `execute_sql` accepts an optional keyword-only `database` parameter. When provided, the name is resolved to a managed database ID once and sent as the `X-Database-Id` header on each query attempt. Without it, behavior is unchanged.

Also worth a look: since this is a new feature (feat:) and the project states it follows SemVer, a minor bump (0.3.0) is the conventional choice over a patch. The repo's prior history is a bit mixed (0.1.0 → 0.1.1 also shipped a feature as a patch), so this is a judgment call — flagging in case it was unintentional.

[claude]

Review

Blocking Issues

• CHANGELOG.md:11-15 — the new ## [0.2.1] section contains only the update_changelog.py boilerplate (- Release 0.2.1) instead of describing the actual change being shipped. PR #11 (feat: add database parameter to execute_sql for managed database scoping) is the unreleased change on main and is user-visible API surface that consumers need documented.

Action Required

• Replace the boilerplate entry under ## [0.2.1] with a real description of the execute_sql database parameter feature from #11 before merging. See the inline suggestion.
• Optional: reconsider whether a feat: warrants a minor bump (0.3.0) rather than a patch under the SemVer policy the changelog header advertises.