[Epic]: Multi-forge repo auth — GitLab (SaaS + self-hosted), local-dev + CI

## Executive Summary

We want **repo-as-principal auth to cover GitLab** — across **gitlab.com and self-hosted instances**, for both **local-dev developers** (OpenCode CLI) and **GitLab CI** — because our primary customer is on GitLab, while the platform today is GitHub-only (GitHub Actions OIDC + GitHub-App-keyed Sources, ADR-0047). This epic exists to remove that forge lock-in so GitLab repos get the same Source attribution/budgeting GitHub already has.

## Strategic Intent

Make the Source model multi-forge: one resolve-and-stamp path serves GitHub CI, GitLab CI, and local-dev, with GitLab instances added by configuration, not code.

## Problem Statement

- **Customer:** their developers and CI are on GitLab (SaaS + self-hosted); none of it can be attributed/budgeted per repo today.
- **Platform:** Sources are keyed by GitHub `repository_owner_id` and only GitHub Actions OIDC is trusted — a GitLab repo's Source cannot even exist, and Authorino trusts no GitLab issuer.
- **Business:** no per-repo cost/RBAC for the main customer's usage.

## Desired Outcome

A GitLab CI pipeline (any trusted instance) and a GitLab developer both bill to their repo's Source account via `/v1/resolve` + Authorino, with self-hosted instances added by editing a values list.

## Scope (In / Out)

### In Scope
- Provider-qualified Source identity `(provider, instance, external_id)` + operator create-Source in `lightbridge-repo-auth`; `/v1/resolve` GitLab claim support (backward-compatible with GitHub rows).
- Authorino trust for a values-driven list of GitLab OIDC issuers (gitlab.com + self-hosted) + claim mapping + synthetic identity/sentinels.
- `ai-helm-values` GitLab issuer/JWKS list + AuthConfig resolve branch (values-repo-first).
- GitLab CI `id_tokens` setup docs + example `.gitlab-ci.yml`.

### Out of Scope
- A GitLab App / webhook auto-enrollment control plane (enrollment is operator-claim in v1, ADR-0049).
- Changes to the OpenCode plugin (local-dev is already forge-neutral, ADR-0077).
- Project-level (vs namespace-level) Sources unless specifically needed.

## Source of truth (links)

- ADR: `ADORSYS-GIS/ai-helm` `docs/adr/0078-multi-forge-repo-binding-gitlab-oidc.md` (branch `feat/local-dev-repo-auth`).
- Sibling GitHub path: ADR-0047. Local-dev: ADR-0077 (+ vymalo/opencode-oauth2#64). Operator-claim: ADR-0049.

## Stakeholders

Product/Tech/Delivery/Security: @stephane-segning. Consumer: the GitLab primary customer.

## Key Assumptions

- GitLab `id_tokens` (configurable `aud`) is available on the customer's instances (GitLab ≥ 15.7).
- Self-hosted instances can expose OIDC discovery/JWKS reachable from the cluster (egress + CA trust).
- Namespace-level binding (`namespace_id`) is the right default granularity.

## Constraints

- Instance qualifier is mandatory in the Source key (numeric ids collide across instances).
- Backward-compatible migration for existing GitHub Sources.
- Authorino/values changes are values-repo-first (ADR-0056).
- Each trusted issuer is a security-sensitive principal source.

## Risks

| Risk | Prob | Impact | Mitigation |
|---|---|---|---|
| Self-hosted JWKS unreachable / untrusted CA | Med | High | Per-instance egress + CA trust checklist; validate before enabling. |
| Cross-instance id collision | Med | High | Instance-qualified key (non-optional). |
| Manual enrollment doesn't scale | Med | Med | Operator-claim v1; defer webhook control plane to a later ADR. |
| Migration breaks GitHub rows | Low | High | Additive migration mapping GitHub → `github:github.com:`; regression tests. |

## Success metrics

| Metric | Current | Target | Source |
|---|---|---|---|
| GitLab repos attributable to a Source | 0% | 100% for enrolled repos | Authorino `x-account-id` / gateway usage |
| Add a self-hosted instance | code change | values-only edit | `ai-helm-values` diff |
| Forge coverage | GitHub only | GitHub + GitLab (SaaS + self-hosted) | AuthConfig issuers |

## Child User Stories / Tickets

- [ ] ADORSYS-GIS/lightbridge-repo-auth#3 — Provider-qualified Source identity + operator create-Source + GitLab claims. **(also unblocks local-dev GitLab — ADORSYS-GIS/ai-helm-values#300 / vymalo/opencode-oauth2#64)**
- [ ] ADORSYS-GIS/ai-helm#589 — Authorino multi-issuer GitLab OIDC trust + claim mapping (values-driven).
- [ ] ADORSYS-GIS/ai-helm#590 — `ai-helm-values` GitLab issuer/JWKS list + AuthConfig resolve branch (values-repo-first, lands last).
- [ ] ADORSYS-GIS/lightbridge-repo-auth#4 — GitLab CI `id_tokens` setup docs + example `.gitlab-ci.yml`.

**Suggested sequence:** ADORSYS-GIS/lightbridge-repo-auth#3 (Source identity, shared with local-dev) → ADORSYS-GIS/ai-helm#589 (Authorino trust) → ADORSYS-GIS/ai-helm#590 (values, last) ; ADORSYS-GIS/lightbridge-repo-auth#4 docs after field names settle.

**Related epic:** vymalo/opencode-oauth2#64 (local-dev repo auth) — shares the `lightbridge-repo-auth` generalization (#3).

## Human accountable owner

@stephane-segning

## AI Usage Declaration

Research, Drafting, Ticket decomposition, Technical proposal. AI researched the GitHub-coupled surfaces and drafted ADR-0078 + this decomposition. AI output is not truth; the owner verifies.

## Human verification completed

- [ ] Intent checked against source of truth
- [ ] Scope reviewed
- [ ] Technical feasibility reviewed (GitLab OIDC on the customer's instances)
- [ ] Risks reviewed
- [ ] No unverified AI claim remains
- [x] I am the accountable owner and accept responsibility for this epic.

Start with ADR-0078 and compare the existing GitHub path in ADR-0047, then read child issues lightbridge-repo-auth#3, ai-helm#589, ai-helm#590, and lightbridge-repo-auth#4. Trace the /v1/resolve flow and the values-repo-first AuthConfig changes across the named repositories. Done means the child tickets are implemented, GitHub remains compatible, GitLab SaaS and configured self-hosted issuers resolve to the correct Source, and the CI setup is documented.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.