Support configurable source providers and mixed-provider repository workflows

[eshulman2]

Problem

Forge currently models repositories primarily as GitHub-shaped owner/repo values and keeps workflow-level fields such as current_repo, current_pr_number, and pr_urls. This cannot safely represent a workflow spanning repositories on different source providers or provider instances—for example, a GitHub PR and a self-managed GitLab MR that happen to share native number 42.

The product roadmap in PR #157 defines the intended direction: the source provider and connection belong to each repository, not to the workflow globally, and each repository change progresses independently under aggregate workflow gates.

Proposed capability

Introduce configurable source-control connections and canonical repository references, then place the existing GitHub behavior behind a provider-neutral contract.

Example repository configuration:

id: payments-api
provider: github
connection: public-github
namespace: acme/payments
default_branch: main
change_request_mode: fork

A connection should hold provider-specific API/base URLs, credential references, webhook verification configuration, TLS/CA configuration, proxy settings where applicable, and allowed namespaces. Credentials must not be embedded in Jira metadata or agent context.

Workflow state should track a map of per-repository work items rather than one global current PR:

• canonical repository identity and configured connection
• source revision and working branch
• PR/MR identity, URL, and state
• provider-normalized CI/check state
• review state
• execution, retry, and error state
• explicit dependencies on other repository work items

The durable identity of a change request should be composite, such as (connection, repository_id, native_id), because native PR/MR numbers are provider-local.

Delivery slices

1. Define SourceControlProvider, repository reference, connection, normalized event, change-request, review, and check-run contracts.
2. Adapt existing GitHub behavior to those contracts without regression.
3. Migrate workflow checkpoints from single-current-PR fields to per-repository work items.
4. Add GitLab.com support.
5. Add configurable self-managed GitLab connections, including private CA and capability discovery.
6. Support one workflow spanning mixed GitHub/GitLab repositories with independent change requests and aggregate gates.

Acceptance criteria

• Repository configuration selects a provider and named connection independently for each repository.
• No workflow node imports a concrete GitHub or GitLab client.
• GitHub behavior passes the provider contract suite without regression.
• Interleaved/replayed events update only the addressed repository work item.
• PR/MR routing uses composite identity rather than native number or title parsing.
• Aggregate CI, review, and completion policy is derived explicitly across required repository changes.
• A test workflow coordinates at least one GitHub PR and one GitLab MR.
• Connection credentials and CA material never enter prompts or logs.

Context

• Roadmap: PR docs: add Forge product roadmap #157, “Source control provider platform”
• The roadmap recommends landing provider contracts and the GitHub adapter before adding GitLab implementations.