Hardcoded GraphQL pagination limits prevent analysis of large PRs

# Hardcoded GraphQL pagination limits prevent analysis of large PRs

## Summary

The Claude Code Action has hardcoded GraphQL pagination limits of 100 items for files, commits, comments, and reviews, which prevents comprehensive analysis of large pull requests. These limits are not configurable and there's no pagination logic to fetch additional items beyond the first 100.

## Problem

When analyzing PRs with more than 100 files, commits, or comments, the action silently truncates data without warning, potentially missing critical code changes or context.

## Evidence

Initially we found this limitation and behavior while running the `anthropics/claude-code-action@beta` through the default GitHub Repo setup via Claude Code. Having examined the repository myself, it does appear the prompt is being built with the truncated 100 changed file list.

The hardcoded limits are defined in [`/src/github/api/queries/github.ts`](https://github.com/anthropics/claude-code-action/blob/3486c33ebfa03d71c98e72621759471c45388443/src/github/api/queries/github.ts):

```typescript
// PR_QUERY
commits(first: 100)
files(first: 100)
comments(first: 100)
reviews(first: 100)
// Nested in reviews:
comments(first: 100)

// ISSUE_QUERY
comments(first: 100)
```

Analysis of the codebase confirms:

- No cursor-based pagination implementation exists
- No configuration options to adjust these limits
- No warning when data is truncated
- GraphQL client performs single queries without continuation logic

## Impact

For large repositories or comprehensive PRs:

- **Files beyond the first 100 are not analyzed**, potentially missing critical changes
- **Commit history is truncated**, losing context for complex features
- **Review discussions are incomplete**, missing important feedback
- **Silent failures** - users don't know their PR analysis is incomplete

## Proposed Solutions

### Option 1: Make limits configurable

Add action inputs to control pagination limits:

```yaml
- uses: anthropics/claude-code-action@beta
with:
max_files: 500
max_commits: 200
max_comments: 300
max_reviews: 100
```

### Option 2: Implement full pagination

Add cursor-based pagination to fetch all available data:

- Use GraphQL `pageInfo` fields for cursor management
- Implement batch fetching with reasonable chunk sizes
- Add timeout protection for extremely large datasets

### Option 3: Hybrid approach

- Default to reasonable limits (current 100)
- Allow configuration to increase limits
- Add warning messages when limits are exceeded
- Provide option to enable full pagination

## Questions

1. Are the 100-item limits intentional performance/cost constraints?
2. Would you accept a PR implementing configurable limits?
3. Is there a preferred approach among the proposed solutions?

## Environment

- **Repository**: Large monorepo with PRs often exceeding 100 files
- **Use case**: Comprehensive code review automation
- **Current workaround**: Manual PR splitting (not always feasible)