ci/fix: improve error handling in release-info script

[kevinmingtarja]

Description

Previously, errors in this script were only logged to the console. This is dangerous as failures during CI won't be caught, unless you look at the logs. Meaning, the script could generate bad output files and still be released to our releases bucket. And it could go unnoticed for a while, since it looked like the CI pipeline is all green.

Checklist

All PRs should check the following boxes:

• I have given this PR a title using the
  Conventional Commits syntax, leading with fix:,
  feat:, chore:, ci:, etc.
  • The title should also be used for the commit message when the PR is squashed and merged.
• I have formatted and linted my code with Trunk, per the instructions in
  the contributing guide.

If the PR includes a code change, then also check the following boxes. (If not, then delete the
next section.)

• I have added an entry to the CHANGELOG.md file.
  • Add to the "UNRELEASED" section at the top of the file, creating one if it doesn't yet exist.
  • Be sure to include the link to this PR, and please sort the section numerically by PR number.
• I have manually tested the new or modified code, and it appears to behave correctly.
• I have added or updated unit tests where appropriate, if applicable.

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (2)

tools/release-info/versioninfo.ts:43

• [nitpick] Consider including the original error as the cause (e.g., using { cause: e } if available) to preserve the stack trace for easier debugging.

throw new Error(`Error fetching latest release tag of ${owner}/${repo}: ${e}`);

tools/release-info/versioninfo.ts:76

• [nitpick] Consider including the original error as the cause (e.g., using { cause: e } if supported), so the complete error context is preserved for troubleshooting.

throw new Error(`Error fetching release tags of ${owner}/${repo}: ${e}`);