fix: avoid large REST release-list responses

[cxzhong]

Summary

• scan recent release IDs and tag names through GraphQL after getReleaseByTag returns 404
• fetch full REST release data only for exact tag matches, preserving draft reuse and canonicalization
• fall back to the existing REST pagination path when GraphQL is explicitly unavailable (for example, Gitea)
• add regression coverage for large release-list avoidance, pagination, draft hydration, and the REST compatibility fallback
• regenerate dist/index.js

Root cause

The v3.0.2 draft-release fallback asks the REST releases endpoint for 100 releases per page. REST embeds every release's asset metadata, so repositories with many release assets can return very large responses before a missing-tag release can be created. For sagemath/sage, the first page was 37,415,077 bytes and took 11.12 seconds during reproduction.

The GraphQL fallback requests only databaseId and tagName. A full REST release is then loaded only when the tag matches, so existing draft behavior is retained without downloading unrelated asset metadata.

Validation

• npm run fmtcheck
• npm run typecheck
• npm run build
• npm test (184 tests; coverage thresholds pass)
• live sagemath/sage comparison: 100-release REST page 37,415,077 bytes / 11.12 s; 100-node GraphQL metadata query 0.99 s
• live draft probe in cxzhong/action-gh-release: REST tag lookup returned 404 while GraphQL returned the same release with isDraft: true; the temporary draft was deleted afterward
• Gitea compatibility is covered by the GraphQL-unsupported REST fallback unit test; the external Gitea harness could not run locally because Docker socket access is unavailable

Fixes #829

[MRK2009]

It got conflicted.

[cxzhong]

It got conflicted.

It should regenerate the index.js