Resolve pipelines, branches, and commits in Orbit context and grep

What does this MR do and why?

The Orbit CLI resolves branches, pipelines, and commits, and keeps its own list of grep scopes, by calling REST directly. That puts entity knowledge in the client, and MCP and other clients don't get the same behavior. This MR moves both into the Orbit endpoints so the CLI can pass tokens and scope names straight through.

POST /api/v4/orbit/context resolves three more types:

• Pipeline: Pipeline[id], gid://gitlab/Ci::Pipeline/<id>, or a pipeline URL. Summary: status, ref, commit, source, merge request, jobs, and failed jobs.
• Branch: path@ref. Summary: head commit, its open or latest merge request, and its latest pipeline with failed jobs.
• Commit: path@<sha> when no branch has that name, or a commit URL. Summary: title, message, author name, latest pipeline, the merge requests that contain it, and changed files with line ranges.

The response version moves to 1.3.0. The new types have no graph expansion and return expansion_unsupported_type.

GET /api/v4/orbit/grep maps scope aliases such as mr, issue, and comment, and node type names such as MergeRequest, to scope names, so clients send graph kinds as-is. A new branches scope matches branch names in a project. It reads them from the Redis branch-name cache through Repositories::BranchNamesFinder, so it reaches Gitaly only on a cache miss, and it is not in the default scopes. The response version moves to 1.2.0.

References

• CLI follow-up: gitlab-org/orbit/knowledge-graph!2996 (merged), which drops the CLI's scope table and REST calls once this merges.
• Endpoints: !262223 (merged), !256404 (merged), !264100 (merged).

How to set up and validate locally

1. Enable Orbit for a group with a project that has a repository and pipelines.
2. Request a branch: curl --request POST --header "PRIVATE-TOKEN: <token>" --header "Content-Type: application/json" --data '{"tokens": ["<group>/<project>@<branch>"], "response_format": "llm"}' "http://gdk.test:3000/api/v4/orbit/context"
3. Search branches: curl --header "PRIVATE-TOKEN: <token>" "http://gdk.test:3000/api/v4/orbit/grep?project_id=<id>&search=<term>&scopes=branch,mr"

Security

Each new read takes the ability and fine-grained token permission of its REST endpoint:

Read	Ability	Fine-grained permission
Pipeline	read_pipeline	read_pipeline
Branch (context and grep)	read_code	read_branch
Commit	read_code	read_commit
Commit changed files	read_code	read_commit_diff
Commit merge requests	read_merge_request on each	read_commit_merge_request
Pipeline jobs	read_build	read_pipeline_job

• Ref tokens and the branches scope are authorized before any Gitaly call. A missing or unreadable ref returns the same not_found, so a caller cannot probe which refs exist. An invalid ref returns invalid_token at parse time, before any lookup.
• Refs are checked against git ref rules and capped at 255 bytes before any lookup.
• Linked merge requests come from MergeRequestsFinder and are each checked with readable?. A branch's merge request must also come from the same project, so a fork merge request with the same source branch name does not count. Every pipeline goes through one pipeline_readable? check, which the merge request summary's head pipeline now uses too.
• Commit author email is not returned, only the name.
• Job and changed file lists are capped (50 jobs, 100 files), and a cut list is named in summary.truncated.
• The branches scope counts toward the search rate limit like any other scope.
• Gitaly calls are bounded: a branch token makes one FindBranch call, and a commit makes one commit lookup and one diff call (a path@<sha> token tries FindBranch first). Pipelines make none. Pipeline and branch summaries read the log tail and test report of up to 3 failed jobs from object storage, as MR context already does.
• The branches scope uses Repositories::BranchNamesFinder, like the GraphQL branchNames field, so its cost grows with the number of matching branch names. It is opt-in and not in the default scopes.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.