Survive the openvox repo's broken nested tags when picking a release

[miharp]

#472 bumped the git gem from ~> 4.0 to ~> 5.2, and Gemfile.lock is not committed, so CI and fresh local setups now resolve git 5.x. That breaks Repo#newest_release, which every rake references:* invocation without an explicit VERSION goes through: git 5.x's Git::Base#tags re-resolves each tag name while enumerating and raises on the literal tags/2.6.0rc1, tags/2.6.0rc2, and tags/2.6.0rc3 tags that exist in the upstream openvox repository (a fresh clone has them, so CI hits it too):

Git::UnexpectedResultError: Tag 'tags/tags/2.6.0rc1' does not exist.

First seen on #468's CI, whose series feature routes VERSION=8.x through the same resolution (failing run), but master is equally affected for the default no-VERSION path.

The gem offers no non-raising listing (Git::Base#lib is deprecated in 5.x and delegates back to the same path), so newest_release now lists names with a plain git tag --list (new tag_names helper) and parses those, discarding non-version names via filter_map instead of mapping them to version 0.

Verified locally against git 5.2.0: newest_release resolves 8.28.1 from the vendored openvox clone (which carries the three junk tags), and a full bundle exec rake references:openvox run completes.

Worth passing to the openvox maintainers separately: deleting the three tags/2.6.0rc* tags from the repository would remove the hazard at the source.

Assisted by Claude.