Add GitLab as a first-class forge alongside GitHub

[tftio]

Summary

Adds GitLab support as a first-class forge, so worktree pull/merge-request status is no longer GitHub-only. Read-only for this first cut. Per the direction in #365 (this comment), the GitHub and GitLab settings are unified into a single Forges pane with a shared "Pull Request" section, modeled on the per-agent integration rows under Developer.

Refs #365

What's included

• Forge abstraction. A Forge enum detected from the remote host; GitClient parsing returns a forge-tagged ForgeRemoteInfo (with GitLab subgroup support). Per-row state carries a ForgePullRequest sum type (.github / .gitlab) with a shared projection — views read common fields and only branch where the data genuinely differs (GitLab pipelines vs. GitHub status checks).
• GitLabCLIClient shelling out to glab, mirroring the existing gh client (availability, auth status, remote resolution, batched merge-request GraphQL query).
• Per-forge refresh dispatch in the repositories reducer.
• Unified Forges settings pane replacing the separate GitHub pane: a per-forge integration row (enable toggle + CLI availability + auth status + install link) plus one shared Pull Request section (merge strategy, merged-worktree action).

Scope — read-only v1 (being explicit)

GitLab MRs surface their number, state, draft flag, and pipeline status in the sidebar, toolbar, and detail view. Mutations are not implemented yet: merge / close / mark-ready, pipeline rerun, and failing-job log copy remain GitHub-only and are gated behind the .github case (the command palette and reducer skip them for GitLab MRs). Closing the gap toward full parity is the intended follow-up.

Build note (please read — not a blocker)

The second commit pins the build to Xcode 26.3 via a scoped, overridable SUPACODE_DEVELOPER_DIR. Two unrelated toolchain breakages on macOS 26.5 forced this:

• macOS 26.4+ SDKs dropped the plain arm64-macos slice from libSystem.tbd; zig 0.15.2 (pinned by Ghostty) can't link against the arm64e-only stubs and fails to link its own build runner (ziglang/zig#31658, fixed in zig 0.16).
• Xcode 26.5's Swift 6.3 fails to compile the pinned swift-composable-architecture (1.23.1).

Xcode 26.3 satisfies both. The export is guarded and auto-disables when that Xcode is absent (CI / other OS versions are unaffected), and the build scripts defer to any DEVELOPER_DIR the caller already set. It's isolated in its own commit so you can adjust or drop it — flagging it explicitly since the default path is environment-specific. The same commit also makes xcbeautify optional so a missing formatter no longer fails the build.

Testing

• Unit tests: forge detection, GitLab MR GraphQL decoding, glab auth status parsing, pipeline-status mapping, plus a GitLab refresh-dispatch integration test in RepositoriesFeatureTests.
• Confirmed locally: built and ran the app against a real gitlab.com remote — the MR badge/notification, pipeline status, and the unified Forges settings pane all render and behave as expected.

make build-app   # (on Xcode 26.3 per the build note above)
make test

[sbertix]

Sorry, got insanely slow down and I'm trying to rationalize how to fit this.
My concern, UI aside, that I can definitely rearrange later, is that this might not effectively "solve the issue" in a generic-enough way, and the subset of GitLab features introduced is too limited, compared to the GitHub one, to justify the "same level" positioning.
Re-reading #403, I'm wondering whether we might turn this into some hot-swappable CLI-based configs (to support a pre-defined and optional amount of features). I understand this solves your use case, but would you be interested in assessing a broader solution?

[tftio]

Totally fine! So, my concern is that Gits Lab and Hub seem to have semantics different enough that we'd need to push a translation shim of sorts if we wanted to have 100% functional coverage. If that's a big enough blocker, no drama!