CI pill reads 'checks unavailable / check gh' while gh works and PR discovery succeeds (separate-git-dir repo)

Summary

The desktop app's CI combobox shows "CI checks unavailable / Check that gh is installed and authenticated" while gh is installed, authenticated, and answers gh pr view / gh pr checks successfully from the same repo — and while the app's own PR discovery works (the PR banner correctly turned purple/"Merged" for a PR merged externally). The failure is specifically in whatever call fetches check runs, sitting beside a working PR lookup.

Ruled out by direct verification

• gh 2.96.0 installed at C:\Program Files\GitHub CLI\gh.exe, on the MACHINE-scope PATH.
• gh auth status: logged in via keyring, repo + workflow scopes.
• No GH_TOKEN / GITHUB_TOKEN / GH_CONFIG_DIR / GH_HOST overrides present.
• Node spawnSync reaches gh three ways (bare name, full .exe path, shell:true).
• gh pr view and gh pr checks both succeed from the Desktop repo folder AND from the resolved git root.

Remaining suspects (untested from outside the app)

1. Session type. The session ran in a normal checkout, not a Claude-managed worktree; the Auto-archive setting text mentions "the session's worktree", so CI monitoring may bind through one.
2. Separated git dirs. The repo's .git is not a directory: originally an NTFS junction, now a plain gitdir: pointer file to a store outside the repo (C:\Users\<user>\GitRepos\<name>\.git, git's own --separate-git-dir mechanism). git worktree list therefore reports the STORE path as the worktree root rather than the Desktop checkout. If the check-runs fetch resolves the repo via git worktree list (or rev-parse --git-common-dir-derived paths) and then runs gh from that resolved path, it would be operating outside the checkout the session opened. PR discovery evidently survives this; the check-runs call may not.

Environment: Windows 11, Claude Code desktop app, repo hosted on GitHub with Actions runs present. Happy to run instrumented probes on request — the separated-git-dir layout is stable here and easy to reproduce (git init --separate-git-dir).