feat(git): support limiting processed tags

[WaterWhisperer]

Description

Adds a limit_tags git configuration option and matching --limit-tags <N> CLI flag to limit changelog generation to the latest N matched tags when no explicit range or --latest / --current / --unreleased mode is provided.

Motivation and Context

Fixes #844

How Has This Been Tested?

• cargo test
• cargo clippy --tests --verbose -- -D warnings
• cargo +nightly fmt --all -- --check --verbose
• .github/fixtures/test-fixtures-locally.sh test-limit-tags

Screenshots / Logs (if applicable)

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (no code change)
• Refactor (refactoring production code)
• Other

Checklist:

• My code follows the code style of this project.
• I have updated the documentation accordingly (if applicable).
• I have formatted the code with rustfmt.
  • cargo +nightly fmt --all
• I checked the lints with clippy.
  • cargo clippy --tests --verbose -- -D warnings
• I have added tests to cover my changes.
• All new and existing tests passed.
  • cargo test

[welcome]

Thanks for opening this pull request! Please check out our contributing guidelines! ⛰️

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 48.67%. Comparing base (b71d250) to head (f38c92d).
⚠️ Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
git-cliff/src/lib.rs	0.00%	9 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1493      +/-   ##
==========================================
- Coverage   48.86%   48.67%   -0.19%     
==========================================
  Files          26       26              
  Lines        2272     2281       +9     
==========================================
  Hits         1110     1110              
- Misses       1162     1171       +9     

Flag	Coverage Δ
unit-tests	48.67% <0.00%> (-0.19%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cds-amal]

A drive-by thought from the range-endpoint work in #1489. Two ways to ship this feature, side by side:

This PR's workflow. Add a branch to determine_commit_range that formats "tag1..tag2" as a string (with a tag1 == tag2 special case for the single-ref form) and hands it to the legacy range path. Every future range-shaped feature ("first N tags," "since date," "between X and Y") follows the same pattern: another branch in the central function, another string format, possibly another special case.

The range-endpoint workflow. Define last_n_tags(tags, n) -> CommitRange as a single transform, route through transform_range, let the one existing serializer at the git2 boundary handle formatting, get the per-side CLI override for free (so --limit-tags 5 --start-at v1.2.0 becomes "baseline = last 5 tags, CLI clips the left," with no new code).

fn last_n_tags(tags: &Tags, n: usize) -> CommitRange {
    CommitRange {
        left:  tags.nth_from_end(n).map(Endpoint::StartAt),
        right: tags.last().map(Endpoint::EndAt),
    }
}

Smaller blast radius (one transform, no new branch in the central function), and the feature stops being its own entry point and starts being one operator in a small algebra over CommitRange. "First N tags," "between X and Y," "since date" are all the same shape. Compose, don't fan out.

Caveat: this is sequencing, not a blocker. If this PR lands first, the rebase is mechanical (swap the string concat for the typed transform, drop the equality branch, route through transform_range). One round of cleanup, not a redesign. So the real question is just whether to land both in their composed form, or land this now and fold it in later.

[WaterWhisperer]

Thanks, that framing helps a lot.

I kept this PR minimal against the current main flow, but I agree limit_tags fits naturally as a CommitRange transform once #1489 lands. I’m happy to adapt this PR on top of #1489 if maintainers prefer that sequencing, otherwise this can land first and be mechanically folded into the typed range pipeline later.