feat: read the commits with the token of the workflow AND fix: fail when the commits cannot be retrieved AND fix: read every page of the commits of a pull request

[javier-godoy]

Three defects in how the commits of a pull request are read, all of which fail open or fail
intermittently, extracted from #3 so that they can be merged on their own.

Changes

fix: fail when the commits cannot be retrieved	A failure to fetch the commits was turned into an empty list, indistinguishable from a pull request whose commits are all valid, so a rate limited or failing request was reported as a success. The failure is now propagated and fails the action. Close #4
feat: read the commits with the token of the workflow	The request was unauthenticated, which GitHub limits to 60 requests per hour per IP address, shared with unrelated jobs on the same runner. A new input defaults to ${{ github.token }}, so no caller changes; an empty value keeps the anonymous request and warns. Close #8
fix: read every page of the commits of a pull request	The request asked for no page size, received the default of 30 commits and read that page alone, so a longer pull request was checked only in part. It now asks for 100 at a time and follows the Link header. Close #5
build: add typescript devDependency required by ncc	npm run build fails on a clean install without it, because ncc 0.36.1 resolves the TypeScript compiler from the project.
build: rebuild the dist bundle	Rebuilt from the current sources, in its own commit.

Verification

npm test passes (3/3).

javier-godoy/test-repo#23 checks this branch directly, since the reusable workflow in
FlowingCode/GithubActions points at another branch of the action. It has 107 commits with an
invalid message at chronological position 104, and the run reports:

ℹ️ Read 107 commit(s).
##[error]🚫 According to the Flowing Code Commit Message Guidelines, some of the commit messages are not valid.

Position 104 is out of reach both of the default 30-commit page and of a single page of 100, so
only following the pages finds it. Before this branch that pull request was green.

The rest was exercised against the bundle directly:

• the token, by reading a real pull request with and without one — the response reports a limit
  of 5000 with the token and 60 without, and the anonymous read warns;
• the retrieval failure, against a refused endpoint: the action fails with
  🚫 The commit messages could not be checked: … and sets SEMVER_LEVEL=0 rather than
  leaving it unwritten.

Relationship to #3

#3 carries these same three fixes in a branch that also adds the results output and the
reporting inputs, and it fixes #5 differently: through the API client's own paginate, which
is available there because the token is. This branch follows the Link header instead, which
needs nothing but the request that reads the first page.

So whichever merges first, the other needs reconciling: if this one goes in, #3 should be
rebased onto master, where the shared commits drop out as already applied and its own
pagination commit becomes redundant.

🤖 Generated with Claude Code