feat: add per-repo GraphQL fallback before REST for GitLab (#765)

[maciekbanas]

Description

When get_repos() fails for a large GitLab group with the repos_by_org GraphQL query, the code now tries per-repo GraphQL queries before falling back to REST.

Fallback order: repos_by_org query → per-repo GraphQL → REST

The per-repo approach works in two steps:

1. A minimal query (repos_by_org_minimal) lists only project fullPath values from the group — no languages, issues, or repository details — so it succeeds even for very large groups.
2. Each repo is fetched individually with a lightweight query (repo_by_fullpath_light) that omits languages and issueStatusCounts to stay under complexity limits.

REST is only used as a last resort if the minimal listing query itself fails. Individual per-repo query failures are skipped gracefully (the repo is omitted from results with a warning).

Changes

File	Change
R/GQLQueryGitLab.R	New repos_by_org_minimal() and repo_by_fullpath_light() queries
R/EngineGraphQLGitLab.R	New get_repos_from_org_per_repo() + private get_repo_paths_from_org()
R/GitHostGitLab.R	Overrides get_repos_from_orgs() with three-tier fallback; updates get_repos_data()
tests/testthat/	11 new/updated tests, new fixtures, snapshot file deleted for regeneration

Related Issue(s)

Fixes #765

How to test

1. Run devtools::test(filter = "01-get_repos-GitLab") and accept new snapshots.
2. Run full test suite to verify no regressions.
3. To test the fallback manually, use a GitLab instance with a large group that triggers GraphQL complexity errors and verify the verbose output shows Switching to per-repo GraphQL queries... before any REST fallback.

[maciekbanas]

For the time being querying per repo with GraphQL as a fallback does not seem very time-efficient. I will wait with this PR for next releases.