fix: remove 100 tag limit by implementing pagination

[hughesjs]

Summary

This PR fixes the arbitrary 100 tag limit issue described in #44.

Problem

The current implementation silently resets maxTagsToFetch to 10 if a value greater than 100 is specified:

const fetchLimit = (maxTagsToFetch < 1 || maxTagsToFetch > 100) ? 10 : maxTagsToFetch

This causes CI failures for repositories with more than 100 tags, as the action cannot find the correct semver tag within the first 10 results.

Solution

• Removed the arbitrary > 100 cap that was resetting the value to 10
• Implemented cursor-based pagination for the GraphQL tag query, fetching tags in batches of up to 100 (the GitHub GraphQL API limit) until the requested number is reached or no more tags exist

Changes

• index.js: Removed the > 100 check and wrapped the GraphQL query in a pagination loop
• dist/index.js: Rebuilt with npm run build

Backwards Compatibility

This change is fully backwards compatible:

• Default behaviour unchanged (still defaults to 10 if not specified)
• Values ≤100 work exactly as before
• Values >100 now work correctly instead of silently failing

Test Evidence

A dedicated test repository demonstrates this issue in action:

Repository: hughesjs/semver-action-test

Test Case 1: Basic (12 tags)

Demonstrates the issue with v1.0.0 at position 12.

Version	Result	Link
IETF (fails)	"None of the 10 latest tags are valid semver!"	Workflow Run
Fork (passes)	Finds v1.0.0	Workflow Run

Test Case 2: Full Pagination (150 tags)

Proves the fix works with pagination across multiple pages - v1.0.0 at position 150.

Version	Result	Link
IETF (fails)	"None of the 10 latest tags are valid semver!"	Workflow Run
Fork (passes)	Paginates (100 + 50 tags) to find v1.0.0	Workflow Run

The tests use annotated tags with controlled tagger dates to ensure deterministic tag ordering in the API response.

Fixes #44