Fix glab fetch failures from non-repo cwd and nested-group slug truncation

[dhilgaertner]

Summary

• fetchGitLabIssues was running glab issue list -a @me --output-format json with cwd: NSHomeDirectory(). glab issue list shells out to git even when no repo is involved and aborts with "fatal: not a git repository" when the cwd is not a git working tree. Swap to glab api "issues?scope=assigned_to_me&state=opened&per_page=100" — same JSON fields the existing parser already reads (iid, title, web_url, state, labels, references.full), no git-repo dependency. Same pattern Crow already uses in fetchGitLabMRsForReconcile.
• resolveRepoInfo truncated nested-group GitLab slugs because its regex [:/]([^/:]+/[^/:]+)$ only captured the last two path segments. big-bang/product/packages/elasticsearch-kibana collapsed to packages/elasticsearch-kibana, then the reconcile path hit a 404 against a non-existent project. Replaced with a new IssueTracker.extractSlug(fromRemote:) helper (parallel to extractHost) that returns the full path after the host for both SSH and HTTPS remotes and strips a trailing .git.
• Added a IssueTrackerRemoteSlugTests Swift Testing suite mirroring the existing IssueTrackerRemoteHostTests: GitHub SSH/HTTPS, two-level GitLab, nested-group GitLab (HTTPS and SSH — the regression for IssueTracker: glab calls fail with 'not a git repository' and malformed nested-group slugs #232), .git stripping, and unrecognized inputs.

Closes #232

Test plan

• swift test — all 38 tests in 5 suites pass, including the new IssueTracker remote slug extraction suite (7 tests).
• Manual: with no GitLab repo cloned at ~, confirm Crow's GitLab issue tracker now returns assigned issues instead of an empty list.
• Manual: register a worktree whose origin points at a nested GitLab group (e.g. big-bang/product/packages/elasticsearch-kibana) and confirm the merged-MR reconcile flow finds the project (no 404).

🤖 Generated with Claude Code

[dgershman]

Code & Security Review

Critical Issues

None.

Security Review

Strengths:

• The glab api endpoint change eliminates a dependency on git-repo context, which was the root cause of the failure. The query-string parameters (scope=assigned_to_me&state=opened&per_page=100) are static/trusted, so there's no injection risk.
• extractSlug(fromRemote:) only operates on locally-obtained git remote URLs (from git remote get-url), not user-supplied input, so the regex parsing is safe.

Concerns:

• None identified.

Code Quality

Minor: double .git stripping in resolveRepoInfo — resolveRepoInfo (line 1338) strips .git from the URL before passing it to extractSlug, but extractSlug itself also strips .git (line 1381). This is harmless (the second strip is a no-op), but worth noting as a minor redundancy. Not blocking.

Positive observations:

• The extractSlug helper is clean, well-documented, and nonisolated static — easy to test in isolation. The parallel structure with extractHost is a good pattern.
• Comprehensive test coverage: 7 new tests covering GitHub SSH/HTTPS, GitLab two-level and nested-group (both SSH and HTTPS), .git suffix stripping, and unrecognized input — all exercising the exact regression from #232.
• The glab api approach mirrors the existing fetchGitLabMRsForReconcile pattern, keeping the codebase consistent.
• The existing parser for fetchGitLabIssues (reading iid, title, web_url, state, labels, references.full) remains compatible with the glab api JSON response shape since the REST endpoint returns the same fields.

Summary Table

Priority	Issue
Green	Double .git strip between resolveRepoInfo and extractSlug is redundant but harmless

Recommendation: Approve — the fix is well-scoped, addresses both root causes cleanly, and has strong test coverage.