fix(release): resolve an interpreter that has tomllib

[anoop-narang]

./scripts/release.sh prepare minor fails before doing anything:

ModuleNotFoundError: No module named 'tomllib'

tomllib is stdlib only from 3.11, and this script hardcoded python3 in every
helper -- get_version, get_pkg_name, set_version, bump_version, the changelog
update, and the publish-time changelog check. python3 carries no version
guarantee, and this package's own requires-python is >=3.10, so the release
script could not run on the oldest Python the package claims to support.

No workflow runs this script; only a human cutting a release does, which is why
it went unnoticed. The symptom names a missing module, which reads as a broken
checkout rather than a too-old interpreter.

Resolved lazily inside cmd_prepare and cmd_publish -- not at load time, so the
commands that never touch Python (--help, no-args, unknown command) keep
working on a machine without a usable interpreter. Otherwise the message telling
you which interpreter you need is itself gated on having it.

The uv fallback is justified here because prepare already shells out to
uv lock when a uv.lock is present, so a machine able to cut a release already
has uv. Noted in the comment that CI installs with pip, so this concerns the
local release path only.

Verified as bash runs it:

PATH=/usr/bin:/bin  ./scripts/release.sh --help        -> prints usage
PATH=/usr/bin:/bin  ./scripts/release.sh prepare minor -> error: ... python3 is Python 3.9.6
with uv available                                      -> pkg=hotdata, minor bump 0.8.0 -> 0.9.0

No change to what a release does; only which interpreter runs it.

Ported from hotdata-dev/sdk-python-framework#58 and #60, where the script was
byte-identical. hotdata-marimo carries the same pattern and is untouched here.

[claude]

Correctness checks I walked through:

• Every $PY_BIN consumer (get_version, get_pkg_name, set_version, bump_version, update_changelog, the publish-time changelog check) is only reachable from cmd_prepare/cmd_publish, so the deferred resolution covers all of them and the empty default is genuinely unreachable.
• die inside $(resolve_python) exits the subshell, but the assignment inherits status 1 and set -e is in force at that call site (a case branch, not a condition), so the script aborts with the message rather than continuing with an empty PY_BIN.
• --no-project matters on the uv path: set_version rewrites pyproject.toml, and uv must not try to resolve the project around it. uv's own progress output goes to stderr, so the $(get_version) captures stay clean.
• scripts/update_changelog.py is pure stdlib and doesn't need 3.11, so routing it through $PY_BIN is consistency rather than necessity — no behavior change there.
• scripts/publish-workflow.sh:41 runs the same import tomllib in CI but under setup-python pinned to 3.12, so the CI publish path is unaffected by this class of bug.

I did not execute the script; the verification runs in the description are the author's. Two non-blocking notes inline.

[claude]

Prior nits addressed. Interpreter resolution now sits after the usage/need gh checks in both commands, and the >=3.11 request avoids pinning a download mid-release. update_changelog.py is stdlib-only, so --no-project is fine for the one non-heredoc call site.