Fix: GitHub branch pagination

[HarshMN2345]

No description provided.

[greptile-apps]

Greptile Summary

This PR adds configurable pagination to GitHub::listBranches and implements the previously-stubbed createBranch method, accompanied by integration tests covering paginated fetches, empty repositories, and non-existent repos.

• listBranches now accepts $perPage and $page parameters (defaulting to 100 and 1) and correctly guards against non-2xx responses before mapping branch names.
• createBranch is newly implemented: it fetches the tip commit of $oldBranchName via getLatestCommit and POSTs a new ref to the GitHub API, but unlike listBranches it does not check the HTTP status code, so API errors (duplicate branch, missing permissions) are returned silently as plain arrays.
• The new tests use assertEqualsCanonicalizing for the full-list assertion, which is correct, but the per-page assertSame assertions depend implicitly on GitHub's alphabetical branch ordering.

Confidence Score: 4/5

Safe to merge after adding error handling to createBranch; the pagination logic in listBranches itself is correct.

The createBranch implementation omits the HTTP status-code check that was explicitly added to listBranches in this same PR, meaning the method silently returns GitHub error payloads on failure (duplicate branch, 403, etc.).

src/VCS/Adapter/Git/GitHub.php — specifically the createBranch method

Important Files Changed

Filename	Overview
src/VCS/Adapter/Git/GitHub.php	Adds createBranch implementation and rewrites listBranches with pagination support and status-code validation; createBranch lacks the same status-code guard added to listBranches, silently returning error bodies on failure.
tests/VCS/Adapter/GitHubTest.php	Adds pagination, empty-repo, and non-existent-repo tests for listBranches; uses assertEqualsCanonicalizing for the full-list assertion (good), but page-specific assertSame assertions rely implicitly on GitHub's alphabetical branch ordering.

_{Reviews (8): Last reviewed commit: "fix: use assertEqualsCanonicalizing for ..." | Re-trigger Greptile}

[Meldiron]

exact value

[Meldiron]

If failing because of default branch, find a way to deleteBranch()

[greptile-apps]

createBranch silently swallows API errors

The method doesn't inspect the HTTP status code before returning. If GitHub rejects the request (e.g., 422 "Reference already exists", 404 branch not found, 403 permission denied), $response['body'] contains an error object like {"message":"Reference already exists",...} and createBranch returns it as if it succeeded. By contrast, listBranches in this same PR correctly gates its output on $statusCode < 200 || $statusCode >= 300. Callers of createBranch have no way to distinguish a successful ref payload from an error payload without parsing the message key themselves.