fix(release): stop shipping an empty changelog on the tag-push route

[filipeforattini]

v0.3.1's published release notes have no changelog entries at all, and a self-referential compare link:

## What's in 0.3.1

**Full Changelog**: https://github.com/reddb-io/dit/compare/v0.3.1...v0.3.1

Two independent bugs

1. --unreleased is wrong for the tag-push route. It means "commits belonging to no tag". On push: tags: the tag already points at HEAD when the job runs, so nothing qualifies and the body renders empty. v0.3.0 escaped only because it came through workflow_dispatch (release-plz tags first, then dispatches). Fixed by resolving an explicit <prev>..<tag> range, keeping --unreleased solely for when the tag does not exist yet.

2. The compare link 404s from the release-plz side. cliff.toml emitted {{ previous.version }}...{{ version }} verbatim, but the two callers disagree on the v prefix — release-plz passes 0.3.2, release.yml passes v0.3.2 (which is exactly why the heading already has a trim_start_matches). Tags carry the v. Normalised both sides.

Verification

Reproduced the CI condition exactly, in a worktree detached at v0.3.1 (so HEAD == tag, as in the failing run):

	output
before	## What's in 0.3.1 + compare/v0.3.1...v0.3.1, zero entries
after	full entry list + compare/v0.3.0...v0.3.1

Both caller contexts render the prefix correctly now:

• release-plz context (--tag 0.3.2) → compare/v0.3.1...v0.3.2
• release.yml context (v0.3.0..v0.3.1) → compare/v0.3.0...v0.3.1

And the links resolve: v0.3.0...v0.3.1 → 200, the old 0.3.0...0.3.1 → 404.

Run with real git-cliff against this repo's actual history, not a fixture.

Not covered here

The already-published v0.3.1 notes stay wrong until someone regenerates them — that is a separate, outward-facing edit I have not made.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}