fix(credentials): scope GitLab personal tokens to organizations

[TheodoreSpeaks]

Summary

• Store personal GitLab tokens under the organization and connecting user, so the same connection works across accessible workspaces. Tokens remain private; workflow sharing permissions do not change.
• Update connection, lookup, rotation, and disconnect paths to use organization ownership while retaining the workspace as execution context.
• Add a resumable, dry-run-first data migration that preserves credential IDs and re-encrypts ownership bindings. Run it after deployment; duplicate identities and conflicting enrollments fail rather than being overwritten. No new schema migration is needed.

Stacked on #7598.

Type of Change

• Bug fix

Testing

• 801 credential unit tests and 9 PostgreSQL integration tests passed, covering migration, cross-workspace use, identity isolation, revocation, reconnect, rotation, and deletion of the original workspace.
• App/auth type checks, repository lint, API boundary checks, migration safety, and shipping audits passed.
• No staging or production data migration has been run.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Sep 8, 2026 7:40pm UTC

[greptile-apps]

Confidence Score: 4/5

The PR should not merge until the migration safely handles or rejects existing delivery_failed organization enrollments.

Findings

1.  Failed enrollment remains unusable ▶

Summary

• Extends credential contracts, queries, presentation, authorization, and client cache keys for organization-owned personal tokens.
• Rebinds encrypted token envelopes to organization scope and preserves creator-only access across workspaces.
• Adds a dry-run-first, resumable migration and integration coverage for migration, rotation, revocation, deletion, and cross-workspace use.
• The migration currently mishandles an existing delivery_failed organization enrollment, producing a successfully migrated but unusable credential.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Legacy workspace GitLab token] --> B[Validate workspace, owner, enrollment, and ciphertext]
  B --> C[Find organization Connected accounts group]
  C --> D{Existing organization enrollment?}
  D -- No --> E[Create in-progress enrollment]
  D -- Yes --> F[Validate and reuse enrollment]
  E --> G[Re-encrypt token with organization binding]
  F --> G
  G --> H[Set organization owner and clear workspace owner]
  H --> I[Use from accessible workspaces in the organization]

Loading

[greptile-apps]

Failed enrollment remains unusable

When an existing organization enrollment is in delivery_failed state and already has the owner's user ID, this check accepts it and the later update leaves its status unchanged. The migration then binds the credential to that enrollment and reports success, but normal token resolution only accepts invited, in_progress, or completed enrollments. The migrated token is therefore unusable. Reject delivery_failed targets or transition them to in_progress, as the live connection path does.

Knowledge Base Used:

• Database schema and migrations
• Data and identity platform