A repository's forks, labels and webhooks answer `{ items, next_cursor }` #6972

I merged main into the branch and pushed it. The type check is clean, and the tests that cover the change pass: list shape, parity, origins, webhooks, forks and the repo-reads timing. I didn't run the whole suite, since the forge's check does that on the push.

• Why src/http/api.ts conflicted: main moved the forks routes to src/http/api/upstream.ts and the labels routes to src/http/api/labels.ts. I took main's versions of those blocks.
• Pagination ported: The { items, next_cursor } pagination from #4843 now lives in those two modules, so forks and labels still answer a page. Hooks stayed in api.ts. To share the helpers, I exported pageParams and pageOf from api.ts.
• test/api-list-shape.test.ts: main had also dropped user/orgs, user/keys, user/pins and tags from the bare-array allowlist. I kept that and left forks, labels and hooks out too, so the allowlist now holds only commits, origins and origin-apps.

Continues #6972

/forks, /labels and /hooks already answered { items, next_cursor } on this branch, so the only change here is in test/api-list-shape.test.ts. The shape-guard test there still listed the three routes as returning a bare array, and that stale entry is probably what kept the check red. I removed the three allowlist entries.

• Already in place: the routes page with limit (default 50, max 200) and a validated cursor, and a bad limit or cursor is a 422.
• Unchanged: visibleForks still hides a private fork from a stranger. Hooks are still admin-only and show no secret.
• Callers: I found no caller in src/ that reads the bare array.
• Tests: test/list-pages.test.ts already covers the shape, paging, the private fork and the bad limit for all three routes. The guard, list-pages, webhooks, forks and parity tests pass, 39 in all, and tsc is clean. Those tests skip anything that needs a unix socket or git, so the forge's full check is what runs them.
• Not done: I did not touch other lists in src/http/api.ts. I did not look at the #4752 MCP hooks tool the issue flags as a risk; the src/http/mcp.ts search turned up nothing that reads these routes.

To try it, call GET /api/v1/repos/:owner/:name/labels?limit=2 and pass the next_cursor back as cursor.

I merged main into the branch and pushed it. The type check is clean, and the tests that cover the change pass: list shape, parity, origins, webhooks, forks and the repo-reads timing. I didn't run the whole suite, since the forge's check does that on the push.

• Why src/http/api.ts conflicted: main moved the forks routes to src/http/api/upstream.ts and the labels routes to src/http/api/labels.ts. I took main's versions of those blocks.
• Pagination ported: The { items, next_cursor } pagination from #4843 now lives in those two modules, so forks and labels still answer a page. Hooks stayed in api.ts. To share the helpers, I exported pageParams and pageOf from api.ts.
• test/api-list-shape.test.ts: main had also dropped user/orgs, user/keys, user/pins and tags from the bare-array allowlist. I kept that and left forks, labels and hooks out too, so the allowlist now holds only commits, origins and origin-apps.

GET …/forks, …/labels and …/hooks now answer { items, next_cursor } instead of a bare array. A cursor whose row has been deleted now returns 422 invalid_cursor, as branches does, instead of an empty last page.

The type check is clean, and the list-pages, list-shape and parity tests pass. Those tests print "ENOENT … posix_spawn 'git'" errors in this sandbox, but nothing fails.

• Stale cursor: I took the 422 option you offered, not a keyset cursor. The old a cursor no row answers to ends the walk… test now expects 422 on all three routes. A new test deletes the label a page ended on, then reads the next page and expects 422 invalid_cursor. pageOf in src/http/api.ts returns the response itself. The forks and labels routes call it from src/http/api/upstream.ts and src/http/api/labels.ts, which main had split out of api.ts.
• Why not keyset: I didn't look into what visibleForks sorts by. The 422 tells a client to start over, and it fits all three routes with one rule.
• README: The branches paragraph now has a matching sentence for forks, labels and hooks. It says the shape changed, gives the limit and cursor bounds, and says what a deleted row's cursor does.
• Left out: The MCP hooks and repo_labels tools still differ from these routes, as you noted. That belongs in a follow-up issue.

The OpenAPI document now describes { items, next_cursor } for GET …/forks, …/labels and …/hooks, and I opened the MCP follow-up as #6997.

• Contract files: I rewrote getApiV1ReposOwnerName{Labels,Forks,Hooks}.ts the way getApiV1ReposOwnerNameBranches.ts is written. Each summary says { items: [...], next_cursor }, with limit 1 to 200 and the cursor from next_cursor. Each declares query: { limit, cursor } and the invalid_limit and invalid_cursor refusals.
• Deleted-row cursor: The invalid_cursor text also says a cursor naming a row deleted since answers 422.
• Hooks: The hooks summary also says the secret is left out.
• Checks: The type check is clean, and the openapi, parity and list-pages tests pass (379). I haven't fetched the preview's /api/v1/openapi.json since the push.
• #6997: It asks the MCP hooks and repo_labels tools to page like these routes, with the same refusals and a test each.