[OrcaWin]

ELI5

When a GitLab project lives on a different machine than the one you are sitting at, Orca sometimes asked the wrong machine about it. The other machine said "I don't know that repository", and Orca either showed "Access denied" or pretended there were simply no checks and no comments. Now every GitLab request goes to the machine that holds that repo's GitLab sign-in, and a failed request says so, naming that machine.

What Changed

Before

• On a client paired to an Orca server, the GitLab Tasks list, the issue/MR dialog and the right-sidebar MR actions always ran on the client. For a repo owned by the server, the client did not know the repo and answered Access denied: unknown repository path ([Bug]: GitLab Tasks fail with "Access denied: unknown repository path" for repos on a remote host #14603).
• In the Checks panel, MR pipeline jobs and comments were fetched from whichever server was selected in the Active Server dropdown, not from the workspace's host. For an SSH workspace with a server selected, the request went to the wrong machine. Any failure then rendered as "No checks configured" / "No comments" ([Bug]: GitLab Checks panel does not load pipelines or comments for SSH worktrees #24264).

After

• A server-owned repo is read and changed on that server; a local or SSH repo uses this computer's glab (where its GitLab sign-in lives). The Active Server dropdown is never consulted. This covers task lists, todos, the item dialog (details, comments, merge/close/reopen, labels, reviewers, job logs, retry), the right-sidebar MR actions and title edit, ready-for-review, the Checks panel and its job logs, and the paste-a-URL / MR search pickers.
• When a checks or comments read fails and nothing is on screen yet, the panel shows the error in place of the empty-list text, for example Could not load from Build box: glab: not logged in, so a sign-in error says which machine needs glab auth login.

Mechanism

• New forgeCredentialTarget (renderer) turns the row's own host (a task source's host, else the workspace's or repo's executionHostId) into a transport: runtime:E (or a nested key behind E) goes to server E, everything else to local IPC. An unresolved owner is refused, not guessed.
• New gitLabApiFor(selector) returns the gl API for that target. Its server arm reuses the web client's gl-over-runtime-RPC table, which moved out of web/preload-api into runtime/runtime-gitlab-api.ts so desktop and web share one copy. Every window.api.gl.* call site in the renderer (except the row-less rate-limit badge) now goes through it.
• An SSH workspace reached through a paired server keeps ssh:<target> as its host and names the server separately (runtimeOwnerEnvironmentId). Its credentials live on that server, so forgeOwnerHostIdForWorkspace sends it there. A direct SSH workspace still uses this computer.
• "Resolve comments with AI" records the MR's host when the action is queued. The later thread resolve then never looks the repo up by an id that two servers can share.
• The Checks panel keeps checksError / commentsError next to its lists. Setting new checks or comments clears them, so the existing reset paths need no changes.
• This removes 5 Active Server lookups (owner-routing ratchet 226 → 223).

Why

The ownership table from the owner-routing work already says forge calls follow the repo's credentials: server-owned repo → its server, local/SSH repo → this computer. The GitHub task path already worked this way. GitLab still had three separate routing styles: always local IPC, the focused server, and a one-off owner check for ready-for-review. Moving every caller onto one owner-derived adapter fixes both issues at the root. It also stops the next GitLab call from copying the wrong pattern. I chose to reuse the web client's existing RPC method table over writing a second desktop-only one. That keeps one list of GitLab runtime methods and their argument rules, such as stripping the desktop-only owner guard. No wire change: every runtime method used already exists. An old server that lacks the ready-for-review capability gets the existing "update server" message.

Linked Issue

Fixes #14603
Fixes #24264

Visual Proof

N/A for screenshots: the agent environment cannot launch the Electron UI on this machine. The only visible change is in the Checks panel: when the read fails and the list is empty, the error text (destructive color, role="alert") replaces "No checks configured" / "No comments". A rendering test covers it.

Testing

Acceptance tests written first and confirmed failing on origin/main (e41b8e17f0):

• use-task-page-gitlab-loading.test.tsx: a server-owned repo's issue list goes to its server over RPC, not local IPC ([Bug]: GitLab Tasks fail with "Access denied: unknown repository path" for repos on a remote host #14603). Fails on main: local gl.listIssues is called.
• An SSH workspace's MR details are read on this computer while a different server is focused ([Bug]: GitLab Checks panel does not load pipelines or comments for SSH worktrees #24264). Fails on main: the request goes to the focused server.
• checks-list-expanded-details.test.tsx: a failed read renders the error instead of "No checks configured". Fails on main.

Plus: gitlab-owner-api.test.ts (server/SSH/local routing, SSH workspace behind a server, task-source repo id, unresolved owner rejects), the polling test (a failed MR read sets an error naming the machine), and updated job-log, hosted-review action and URL-lookup tests.

• I manually tested these changes locally
• Automated tests added/updated, or explained why not below

pnpm tc, focused vitest suites (36 files), oxlint, pnpm run check:code-quality:changed, the owner-routing ratchet (pruned), and the localization checks pass locally.

Review

Agent skill upstream boundary

• Not applicable, or this change copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.

Notes

• SSH: SSH repos keep using this computer's glab, which main runs against the SSH host as before. Only the choice of transport changed.
• Folder workspaces: these have no GitLab project; nothing changes for them.
• Mixed versions: no new RPC methods or fields. Runtime calls now name the repo as id:<repoId>, the selector the web client already sends.
• Web client: uses the same shared table it did before.
• Windows/Linux/macOS: there are no platform-specific paths.

Checklist

• This PR is small and focused
• I explained what changed and why (ELI5, the user-facing before/after, the mechanism, and why over the alternatives)
• Before/after screenshots or videos attached for UI changes, or N/A with reason
• Self-reviewed for correctness, security, and performance
• Cross-platform, SSH/remote, and path/shortcut impact considered (or N/A)
• pnpm lint, pnpm typecheck, pnpm test, and pnpm build pass (or CI will cover; local preferred)