Sync GitLab main through the GitHub gate

[yuezengwu]

What changed

• Synchronize commits created on the temporary self-managed GitLab main branch.
• Preserve commit ancestry so GitHub and GitLab main can converge without force pushes.

Safety

• This PR remains a draft while checks run.
• The synchronization guard marks it ready and merges it only after every check passes.
• The repository review requirement is bypassed only for this checked synchronization PR.
• Merge commit is enabled only for the merge window and immediately disabled again.

Validation

• The guard verified a safe fast-forward relationship or identical file trees.
• GitHub required checks remain authoritative.

[baixiaohang]

Review by baixiaohang-code-reviewer - PR #1822

Recommendation: follow-up fix required

• Rationale: the PR was already merged when the review request arrived, but the new provider-neutral archive query can archive a chat while a cross-provider entity is still open.

Risk level: A

• Path baseline: includes apps/cli/** and packages/client/**.
• Semantic lift: also changes the GitLab mapping schema and core SCM/chat routing.

Review findings

❌ 1. sweepMapped does not evaluate every mapping attached to an SCM-origin chat. The scm_mappings CTE includes GitHub rows only when metadata.source = 'github' and GitLab rows only when metadata.source = 'gitlab', while both follow APIs allow either provider to be attached to an existing chat. A GitHub-origin chat with a terminal GitHub mapping plus an open GitLab mapping (or the inverse) therefore passes the NOT EXISTS check and is archived early. Please build the terminal-state set from both mapping tables for every GitHub/GitLab-origin chat, and add a mixed-provider regression case. [packages/server/src/services/chat-archive.ts:89]

Action taken

• Submitted this post-merge comment; GitHub merged the synchronization PR three seconds after it became ready for review, so an approve/request-changes review was no longer possible.