[Feature]: Add GitHub Enterprise Server support

### Description

Support connecting projects to **GitHub Enterprise Server (GHES)** — self-hosted GitHub installations reachable at a customer-controlled hostname (e.g. `github.mycompany.com`). Today, both OAuth URLs and REST API base URLs are hardcoded to `github.com` / `api.github.com`, so enterprise customers cannot use this platform against their internal GitHub deployment.

This is the lowest-effort multi-provider change: the GitHub REST API v3 surface is identical between github.com and GHES — only the base URLs differ.

### Use case

Enterprise customers who host their own GitHub Enterprise Server cannot use code stored in their internal repos with this platform. Adding GHES support unlocks adoption by any organization running GHES (which is most regulated industries, many large enterprises, and most Amazon-internal-style setups). The same users who today cannot try the product would be able to point it at their own GitHub instance.

### Area

Backend (Lambda)

### Additional context

## Current state

GitHub URLs are hardcoded in several places:

- `lambda/github/index.js:63,86` — OAuth authorize + token endpoints hardcoded to `https://github.com/login/oauth/...`
- `lambda/github/index.js:145,205,240,279` — REST API calls hardcoded to `https://api.github.com`
- `lambda/create-pr/create-pr.js:28,45` — PR create + list hardcoded to `https://api.github.com`

The data model is already partially prepared:

- `frontend/src/services/projects.ts:9` — `gitProvider: 'github' | 'gitlab'` field exists on `Project`
- `lambda/github/index.js:111` — backend stores `provider: 'github'` in the git-connections table

But there is no `provider = 'github-enterprise'` variant anywhere yet, and nothing exposes a custom host.

## Proposed implementation

### 1. Config surface

Treat a GHES connection as a distinct provider (`github-enterprise`) that carries a user-supplied `hostName`. Derived URLs (no new env vars needed for the defaults):

| Provider | OAuth base | API base |
|---|---|---|
| `github` | `https://github.com` | `https://api.github.com` |
| `github-enterprise` | `https://` | `https:///api/v3` |

Per the GitHub docs, GHES exposes the REST API at `/api/v3` on the same host as the web UI.

### 2. Secrets model

OAuth apps are per-GHES-instance, so each instance needs its own `client_id` / `client_secret`. Extend the Secrets Manager secret schema:

\`\`\`json
{
\"github\": { \"client_id\": \"...\", \"client_secret\": \"...\" },
\"github-enterprise\": {
\"\": { \"client_id\": \"...\", \"client_secret\": \"...\" }
}
}
\`\`\`

The admin/operator registers an OAuth app on their GHES instance and adds the credentials to the secret once per host.

### 3. Refactor `lambda/github/index.js`

Extract a small URL resolver:

\`\`\`js
function resolveGitHubUrls(connection) {
if (connection.provider === 'github-enterprise') {
return {
oauthBase: \`https://\${connection.host}\`,
apiBase: \`https://\${connection.host}/api/v3\`,
};
}
return { oauthBase: 'https://github.com', apiBase: 'https://api.github.com' };
}
\`\`\`

Thread `{oauthBase, apiBase}` through every call site that currently hardcodes a URL. Same for `lambda/create-pr/create-pr.js`. Headers (`Authorization: Bearer`, `Accept: application/vnd.github+json`) stay identical.

### 4. DynamoDB `git-connections` shape

Add a `host` field when `provider === 'github-enterprise'`. Keyed on `(userId, provider, host)` so a single user can connect both github.com and one or more GHES instances.

### 5. Frontend

- `CreateProjectModal.tsx` — add a provider selector (GitHub / GitHub Enterprise) as the first sub-step. If GHES: prompt for hostname.
- `GitHubConnectButton.tsx` — pass provider + host to the auth URL lambda.
- `services/projects.ts` — extend `gitProvider` union to `'github' | 'github-enterprise' | 'gitlab'`.
- Persist the selected host on the project so subsequent API calls know which base URL to use.

### 6. Terraform

- `terraform/modules/git/main.tf` — no schema change required (DynamoDB is schemaless), but update the secret resource to seed the new shape.
- Document that operators must pre-register a GHES OAuth app per host.

## User flow

1. User clicks **Create Project**.
2. Step 1 — **Choose git provider**: `GitHub.com` / `GitHub Enterprise Server` (new).
3. If GHES: user types the host (`github.mycompany.com`). A lightweight `GET https:///api/v3` reachability check validates the input.
4. User clicks **Connect** → redirected to `https:///login/oauth/authorize?...` with the host-specific `client_id`.
5. GHES redirects back to our callback with `?code=...`. Lambda exchanges it at `https:///login/oauth/access_token` and stores the token in SSM (scoped by host) + DynamoDB row `{userId, provider: 'github-enterprise', host, parameterName}`.
6. Repo picker lists repos from `https:///api/v3/user/repos`.
7. From here the flow (branch list, file tree, PR create, PR comments) is identical — only the base URL differs.
8. Disconnecting removes the SSM parameter and DynamoDB row for that `(user, host)` pair.

## Out of scope

- GitHub.com → GHES migration of existing projects.
- Supporting self-signed / private-CA TLS for GHES (assume hosts have publicly trusted certs, call out as a follow-up).

## Related

- #14 Multi-repo support — independent but complementary
- #50 Add CodeCommit — sibling provider request
- Sibling issues for GitLab and GitLab Enterprise (to be filed alongside this one)

Start by reading the hardcoded GitHub URL call sites in lambda/github/index.js and lambda/create-pr/create-pr.js, then inspect CreateProjectModal.tsx, GitHubConnectButton.tsx, services/projects.ts, and terraform/modules/git/main.tf. Trace the connection, secret, DynamoDB, SSM, repository, and pull-request flows. Done means GHES hosts can be configured and used end to end while existing GitHub.com behavior remains intact.

Written by the indexing model from the issue text.