GitLab GraphQL follow-up: inventory remaining REST calls and prioritize entry loading

Following up on @martinjagodic's request in #6034. I checked the GitLab backend at `a35d0fdaeba0dda9436d7941130ed4911353821b` and listed the REST calls that still run with `use_graphql: true`.

The existing GraphQL path covers `listAllFilesGraphQL` and batched file content/last-commit reads through `readFilesGraphQL`. It does not replace every entry-loading or editorial workflow request.

### Remaining REST reads

Paths below are relative to `api_root`; `:id` is the encoded project path.

| Operation | REST path | Current caller |
| --- | --- | --- |
| Current user and project permissions | GET `/user`, GET `/projects/:id` | `user`, `hasWriteAccess` |
| Paginated collection entries | GET/HEAD `/projects/:id/repository/tree` | `listFiles`, cursor traversal |
| Single-entry/file content, including LFS downloads | GET `/projects/:id/repository/files/:path/raw` | `readFile` |
| File author and update time outside the batch GraphQL path | GET `/projects/:id/repository/commits?path=...&ref_name=...` | `readFileMetadata` |
| Branch details and permissions | GET `/projects/:id/repository/branches/:branch` | `getBranch`, `getDefaultBranch` |
| File existence and blob ID | HEAD `/projects/:id/repository/files/:path?ref=...` | `isFileExists`, `getFileId` |
| Changes between refs | GET `/projects/:id/repository/compare` | `getDifferences` |
| Branch membership of a commit | GET `/projects/:id/repository/commits/:sha/refs` | `isShaExistsInBranch` |
| Editorial merge requests and rebase status | GET `/projects/:id/merge_requests`, GET `/projects/:id/merge_requests/:iid` | `getMergeRequests`, `rebaseMergeRequest` |
| Preview/build statuses | GET `/projects/:id/repository/commits/:sha/statuses` | `getMergeRequestStatues` |

In particular, [`entriesByFolder`](https://github.com/decaporg/decap-cms/blob/a35d0fdaeba0dda9436d7941130ed4911353821b/packages/decap-cms-backend-gitlab/src/implementation.ts#L288) still calls REST `listFiles`, `readFile`, and `readFileMetadata`. [`allEntriesByFolder`](https://github.com/decaporg/decap-cms/blob/a35d0fdaeba0dda9436d7941130ed4911353821b/packages/decap-cms-backend-gitlab/src/implementation.ts#L317) selects the batched GraphQL reader, but its cache-validation callbacks still include REST branch, compare, refs, and file-ID requests. File collections and single-entry reads also retain REST.

### Remaining writes

- POST `/projects/:id/repository/commits`: create/update/delete files, including new editorial branches.
- POST `/projects/:id/merge_requests`: create an editorial merge request.
- PUT `/projects/:id/merge_requests/:iid`: update labels or close it.
- PUT `/projects/:id/merge_requests/:iid/rebase`: rebase it.
- PUT `/projects/:id/merge_requests/:iid/merge`: publish it.
- DELETE `/projects/:id/repository/branches/:branch`: delete the editorial branch.

These are an inventory of remaining REST calls, not a claim that every endpoint has a compatible GraphQL replacement. Raw/LFS downloads and mutations need a GitLab API/version check before deciding to port them.

### Suggested first step

Start with paginated collection browsing and the remaining per-file content/metadata reads. Compare request counts and load times with REST on the same collection, then handle editorial workflow operations separately. Keep cursor behavior, permissions, cache invalidation, binary/LFS content, and self-hosted GitLab compatibility covered. GraphQL complexity limits already have a separate report in #7627, and token refresh is covered by #7931/#7932.

Source: [API implementation](https://github.com/decaporg/decap-cms/blob/a35d0fdaeba0dda9436d7941130ed4911353821b/packages/decap-cms-backend-gitlab/src/API.ts) and [backend callers](https://github.com/decaporg/decap-cms/blob/a35d0fdaeba0dda9436d7941130ed4911353821b/packages/decap-cms-backend-gitlab/src/implementation.ts).

@martinjagodic, does the collection-browsing path look like the right first piece?

Start in packages/decap-cms-backend-gitlab/src/API.ts and implementation.ts, focusing on entriesByFolder, listFiles, readFile, and readFileMetadata. Compare collection request counts and load times between the REST and GraphQL paths, while checking cursor behavior, permissions, cache invalidation, binary/LFS content, and self-hosted GitLab compatibility. Done should include a scoped, validated priority for the first migration piece.

Written by the indexing model from the issue text.