Expose the resolved git tag name via the CLI (monorepo tagTemplate is unreachable)

Summary

There's no way to ask versionize what git tag it just created. For a single-project repo you
can assume v{version} and be right. As soon as tagTemplate is in play — which is the norm
for monorepos — any downstream tooling has to reimplement versionize's tag resolution, and
that means parsing .versionize and duplicating the template logic.

Why this matters

We drive GitLab releases from versionize in CI. The release step needs the tag name, because
the release object attaches to a tag. Today the CI template hardcodes v${VERSION}, which is
correct for single-package repos and silently wrong for every monorepo package:

what versionize created:   PkgB/v1.0.1
what CI can construct:     v1.0.1

The release then hangs off a tag that doesn't exist, and two packages that happen to share a
version number also collide on the release name.

What I tried

inspect looked like the natural home for this, and 2.6.0 added tag-version printing to it
(#197) — but it returns the version, not the tag:

$ versionize --proj-name PkgB inspect
1.1.0
$ versionize --proj-name PkgB --tag-only inspect
1.1.0            # hoped for PkgB/v1.1.0

The tag name is only available as prose on stdout during a release run
(tagged release as PkgB/v1.0.1 against commit with sha ...), which isn't something a CI
script should be scraping.

Proposal

Any of these would solve it:

1. versionize inspect --tag (or --tag-name) — print the resolved tag for the current
   version, honouring tagTemplate and --proj-name.
2. Have --tag-only inspect print the full resolved tag rather than the bare version, if
   that's closer to the original intent of #197.
3. A machine-readable release summary — e.g. --output-json <path> on the release run,
   emitting { "version": "1.0.1", "tag": "PkgB/v1.0.1", "commit": "..." }. This would also
   cover the CI case of needing version and tag together without a second invocation.

Happy to open a PR if you'll say which shape you'd prefer.

Secondary, possibly worth splitting out

versionize changelog can't describe a pending release. It resolves its range from tags,
so it can only run after the release commit and tag exist — which means the release commit
is always inside the range it reports:

$ versionize changelog --version 1.1.0     # before release
Tag for version '1.1.0' not found

$ versionize changelog --version 1.1.0     # after release
### Features
* add a thing (e069524)
### Bug Fixes
* correct a thing (fb881a7)
### Chores
* **release:** 1.1.0  [skip ci]            <- not in CHANGELOG.md

On a config with includeAllCommits: true and the chore section visible, the output can't be
made to match the CHANGELOG.md entry versionize itself just wrote. A --pending mode, or an
option to exclude the release commit, would let CI publish release notes that match the
changelog exactly.

--skip-commit help text doesn't match behaviour. It reads "Skip commit and git tag
after updating changelog and incrementing the version", but it does create the tag (against
the current HEAD). --skip-tag covers the tag separately, so the behaviour looks right and
the help text looks stale — but it's worth confirming which is intended, since it's easy to
build on by accident.

Start with the CLI's inspect and release entry points, especially --tag-only inspect, --proj-name, and tagTemplate resolution. Confirm the preferred output shape with maintainers, then verify that the resolved tag is exposed for monorepo releases without requiring stdout parsing. Treat the pending changelog and --skip-commit concerns as separate work unless they are explicitly included.