GitLab provider: add support for group.sharedProjects (shared repositories)

[gdepuille]

Add support for GitLab shared projects in group queries

Context

When using the GitLab provider with groups, git-workspace currently only fetches projects that are owned by the group via the group.projects GraphQL field. However, GitLab also allows projects to be shared with a group, which are exposed through the group.sharedProjects field.

These shared projects are visible in the GitLab UI but are not currently cloned by git-workspace, which leads to incomplete workspace synchronization when organizations rely heavily on shared repositories.

Changes

This PR updates the GitLab GraphQL query and result handling to:

• Add support for group.sharedProjects

• Merge results from:

  • group.projects
  • group.sharedProjects

• Preserve existing behavior for namespace.projects

• Keep pagination handling consistent with existing implementation

Example

Before:

• GitLab UI shows ~100 repositories
• git-workspace clones only 8 (group-owned)

After:

• All repositories are discovered and cloned
• Includes shared repositories from other groups

Implementation details

• Extend GraphQL query to include:

  • group.sharedProjects

• Update response mapping to merge both result sets

• Handle optional shared_projects field safely

• Deduplicate repositories implicitly via existing logic

Why this matters

Many GitLab organizations structure repositories using:

• shared projects across groups
• platform repositories reused by multiple teams
• centralized infra or common libraries

Without this change, git-workspace silently misses a large portion of accessible repositories.

Backward compatibility

• No breaking changes
• Only adds additional repositories when available
• Existing configurations continue to work unchanged

Tested

Tested against:

• GitLab SaaS
• Groups with only shared projects
• Mixed owned + shared projects
• Pagination enabled responses