Release script skips version bump for packages with only lockfile changes

Describe the bug

has_changes() in scripts/release.py only considers .py and .ts files when deciding which packages to version-bump at release time:

relevant_files = [f for f in changed_files if f.suffix in [".py", ".ts"]]
return len(relevant_files) >= 1

If a sub-package only has lockfile changes between tags (e.g. uv.lock from dependabot), the function returns False and the package's pyproject.toml version is never bumped to the CalVer tag. It keeps whatever stale version is on main.

To Reproduce

Between tags 2026.1.14 and 2026.1.26, the only change in src/git/ was uv.lock:

git diff --name-only 2026.1.14 2026.1.26 -- src/git/
# src/git/uv.lock

The release script skipped src/git/, so pyproject.toml stayed at 0.6.2:

git show 2026.1.26:src/git/pyproject.toml | grep '^version'
# version = "0.6.2"

git show 2026.1.14:src/git/pyproject.toml | grep '^version'
# version = "2026.1.14"

Expected behavior

src/git/pyproject.toml should read version = "2026.1.26" on the 2026.1.26 tag, since the package directory had changes included in that release.

Logs

N/A this is in the release automation, not a runtime issue.

Additional context

Downstream consumers (SBOM generators, CVE scanners) key off the version in pyproject.toml. When it says 0.6.2, advisories with CalVer "fixed in" thresholds never match, so scanners flag the package as vulnerable even though the source is identical to a patched release.

Start in scripts/release.py at has_changes() and inspect how changed files are filtered for package version bumps. Reproduce the 2026.1.14 to 2026.1.26 case with src/git/uv.lock, then verify that the release process updates src/git/pyproject.toml to version 2026.1.26 when the package directory has only lockfile changes.