feat(git-providers): the CMS reads and writes through a provider interface

[viktormarinho]

Stacked on #6939 — review that first; this PR's diff is only the CMS/decofile layer.

The Site Editor was GitHub-only by construction, not by omission. GitDataClient was shaped like GitHub's Git Data API — create a blob, then a tree, then a commit, then move a ref — and GitLab exposes no such plumbing at all, so an interface in that shape has no second implementation. That is what blocked a GitLab storefront from using the CMS.

RepoContentClient states the write side as the intent instead: put these files on this branch, atomically, unless the branch moved. GitHub does it in four calls, GitLab in one; neither leaks through. The read side needed no lift — both providers address tree entries and blobs by object sha, and both accept a commit sha wherever a tree-ish is asked for.

Net: +449 / −1274. decofile/github-git-data.ts and client-for-repo.ts are gone.

The three properties the plumbing carried implicitly

Losing one of these silently was the real risk of this refactor, so each is now an explicit part of the contract:

	what it is for	GitHub	GitLab
expectedHead	the commit coalescer's multi-replica safety	non-forced ref update, 422 → RepoWriteConflict	no branch-level CAS: reads the head and guards every changed file with last_commit_id, because the head check alone leaves a window
rewriteFrom	the squash-rebase	commit first, force-move the ref last — a crash cannot strand the branch	one forced call (start_sha + force); falls back to replacing the branch only when it is protected, which is the one case with a window
copyFromRef	"this path should have the content it has at that ref"	points the new tree at the blob that already exists — zero uploads, which is what the replay used to do by hand	reads and rewrites it

FileChange also carries an optional mode, so the exec bit survives a discard.

Measured, not assumed

Everything above about GitLab came from probing gitlab.com directly (throwaway projects, deleted after):

• multi-file atomic commit via actions[] → 201, one commit, one parent
• optimistic locking is per file: a stale last_commit_id → 400 {"message":"The file has changed since you started editing it: a/one.json"}
• committing onto an existing branch from an earlier start_sha → 400 "A branch called 'main' already exists"
• force: true lifts exactly that refusal — 201, parent = the base sha, prior content gone — except on a protected branch ("not allowed to force push"), and main is protected by default
• execute_filemode: true → mode 100755
• tree rows carry the object sha as id, blobs/:sha/raw serves content, and a commit sha works as a ref
• there is no POST /repository/merge (404): merging a branch means creating an MR and merging it

Testing

• Unit: 219 in content/ + decofile/ — tree walking, the change→tree-entry mapping with modes and copyFromRef, the GitLab action builder, and each conflict classifier.
• E2E: 253 pass. decofile-api, cms-publish-stages, cms-publish-surface and fast-preview-git-sync (35 specs) run green against the new interface with the GitHub stub unmodified. The one failure is mcp-proxy-roundtrip, which fails identically on a clean main — pre-existing, unrelated.
• The squash ordering was verified over real HTTP against the stub: call order is POST /git/trees → POST /git/commits → GET /branches → PATCH /git/refs, i.e. the commit strictly precedes the ref move, and a clean sync issues zero POST /git/blobs.

Known limitations

• GitLab reads block-by-block. Its tree listing carries no blob size, and the decofile cold read refuses the tarball fast path when a size is missing (it pre-validates the aggregate before downloading). Correct, but slower on a large storefront. Fixing it means enforcing the cap during extraction instead of before — a memory-safety guard I did not want to weaken in this PR.
• A clean sync over 300 files still 409s. GitHub truncates a compare's files at 300 with no total, so a copyFromRef replay built from it could be partial — and a partial replay would silently revert the paths it never saw. The guard stays until the interface can express "the resulting tree is exactly this ref's".
• mergeBranches on GitLab leaves a merge request behind, because no direct branch-merge endpoint exists.

---

Summary by cubic

Replaces the GitHub-shaped GitDataClient with a provider-neutral RepoContentClient, so the CMS can read and write through GitHub or GitLab. Writes now express atomic branch intent instead of exposing GitHub’s blob/tree/commit/ref sequence; GitHub still uses four calls, while GitLab uses one.

Implementation

• Makes expectedHead, rewriteFrom, copyFromRef, and file modes explicit in the write contract.
• Guards GitLab changes with per-file last_commit_id because GitLab has no branch-level compare-and-swap.
• Routes repository resolution, error handling, reads, writes, rebases, discards, and fast preview through the provider client.
• Removes the old GitHub-only client and the stale duplicate migration left by the merge.

Validation and limitations

• Unit and E2E suites pass; the GitHub E2E stub remains unchanged.
• GitLab reads block-by-block because tree entries do not include blob sizes.
• GitHub clean syncs over 300 files still return 409 because compare results are truncated.
• GitLab mergeBranches leaves a merge request behind.

^{Written for commit 7ea08d7. Summary will update on new commits.}