[Feature]: Add GitLab Self-Managed support

### Description

Support connecting projects to **GitLab Self-Managed** (formerly \"GitLab Enterprise Edition\" / on-premise GitLab installations at customer-controlled hostnames, e.g. `gitlab.mycompany.com`). This builds on top of the GitLab.com provider: the REST API (`/api/v4`) and OAuth endpoints are identical — only the host differs.

Depends on the foundational GitLab SaaS support being landed first; this issue covers the incremental host-configuration work.

### Use case

Most GitLab-committed enterprises run GitLab Self-Managed on their own infrastructure for compliance, data residency, or network-isolation reasons. Without this, GitLab support only benefits gitlab.com users — a small fraction of GitLab's installed base. Adding self-managed support unlocks the long tail of enterprise GitLab deployments.

### Area

Backend (Lambda)

### Additional context

## Prerequisites

- GitLab (SaaS) support landed first — this issue is an extension of that.
- GitHub Enterprise issue patterns are analogous and can be used as reference.

## Current state

Once GitLab SaaS lands, URLs will be centralized in a provider module (`lambda/git/providers/gitlab.js`, per that issue). This change extends that module to accept a host rather than assuming `gitlab.com`.

## Proposed implementation

### 1. Provider variant

Add `provider = 'gitlab-self-managed'` carrying a user-supplied `host`. URLs derive identically to gitlab.com:

| Provider | OAuth base | API base |
|---|---|---|
| `gitlab` | `https://gitlab.com` | `https://gitlab.com/api/v4` |
| `gitlab-self-managed` | `https://` | `https:///api/v4` |

All other differences from GitHub (MR vocab, `project_id`, refresh tokens, scopes) are the same as for gitlab.com — no additional mapping work.

### 2. Secrets model

Per-instance OAuth application. Extend the secret:

\`\`\`json
{
\"gitlab\": { \"client_id\": \"...\", \"client_secret\": \"...\" },
\"gitlab-self-managed\": {
\"\": { \"client_id\": \"...\", \"client_secret\": \"...\" }
}
}
\`\`\`

Admin registers an OAuth application at `https:///-/user_settings/applications` with scopes `api read_user` and the platform's redirect URI, then seeds the secret once per host.

### 3. Refactor the GitLab provider

Thread `host` through the provider module. The existing function signatures change from `(token, ...)` to `({token, host}, ...)` or a provider-instance pattern that captures the host at construction time. Default host = `gitlab.com` when `provider === 'gitlab'`.

### 4. DynamoDB `git-connections`

Reuse the same extension as the GHES issue: store `host` on the row, key on `(userId, provider, host)` so a user can have both gitlab.com and one or more self-managed instances connected.

### 5. Token refresh

GitLab Self-Managed follows the same refresh-token flow as gitlab.com. The refresh code path inherited from the SaaS issue works unchanged; just hit `https:///oauth/token` instead.

### 6. Frontend

- Extend the provider selector in `CreateProjectModal.tsx` with a fourth option: **GitLab Self-Managed**. When chosen, prompt for host.
- `services/projects.ts` — union becomes `'github' | 'github-enterprise' | 'gitlab' | 'gitlab-self-managed'`.
- Persist the host on the project alongside provider + repo identifier.

## User flow

1. User clicks **Create Project**.
2. Step 1 — **Choose git provider**: GitHub / GitHub Enterprise / GitLab / GitLab Self-Managed.
3. User enters the host (`gitlab.mycompany.com`). A reachability probe against `GET https:///api/v4/version` (unauthenticated — GitLab allows this when `/version` is public, else we detect via `/api/v4/projects` 401 vs. network error) validates it.
4. User clicks **Connect** → redirected to `https:///oauth/authorize?client_id=...&redirect_uri=...&response_type=code&scope=api+read_user&state=...`.
5. Instance redirects back with `?code=...`. Lambda exchanges at `https:///oauth/token`, stores access + refresh token in SSM, writes `git-connections` row `{userId, provider: 'gitlab-self-managed', host, parameterName}`.
6. Repo picker lists user's projects from `https:///api/v4/projects?membership=true&min_access_level=30`.
7. Rest of the flow (branch list, file tree, MR create, MR comments, refresh on 401) is identical — only the base URL differs.
8. Disconnect removes the SSM parameter and the DynamoDB row scoped to `(user, host)`.

## Networking

Self-managed GitLab instances are often inside a customer VPC. Out-of-scope for this issue, but worth noting as a follow-up:

- Self-signed / private-CA TLS — call out as a known limitation; requires either CA trust on the Lambda or a docs workaround.
- VPC-reachable instances — would require Lambda running in the customer VPC or a VPC endpoint, which is a broader deployment-topology change.

This issue assumes self-managed instances are reachable over the public internet with publicly trusted TLS certs. Private-network deployments are a separate track.

## Out of scope

- Private-CA / self-signed TLS trust (follow-up issue).
- VPC-internal GitLab instances (deployment topology, follow-up).
- GitLab CI / pipeline integration.

## Related

- Sibling issue: GitLab (SaaS) support — hard dependency
- Sibling issue: GitHub Enterprise Server support — analogous pattern
- #50 Add CodeCommit

Start by confirming that GitLab SaaS support has landed, then read lambda/git/providers/gitlab.js and the analogous GitHub Enterprise patterns. Trace provider selection in CreateProjectModal.tsx, the provider union in services/projects.ts, and the git-connections persistence flow. Done means self-managed host configuration works through OAuth, repository selection, project persistence, refresh, and disconnect without regressing gitlab.com.

Written by the indexing model from the issue text.