Describe the bug

After the fix for issue #3379, the ESO operator no longer retrieves GitLab CI/CD variables defined at the group level with the environment set to “All (default)”. These secrets are rendered as empty. In contrast, variables scoped to a specific environment are retrieved correctly.

This appears to be a regression or side effect introduced by the recent environment-scoping fix.

To Reproduce

Steps to reproduce the behavior:
1. Define a CI/CD variable in GitLab at the group level, with the environment set to “All (default)”.
2. Use the following SecretStore configuration:

# SecretStore using GitLab provider
apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: gitlab-store
spec:
  provider:
    gitlab:
      auth:
        secretRef:
          accessToken:
            name: EXTERNAL_SECRETS_GITLAB_TOKEN
            key: `external-secret-gitlab-token`

      environment: dev
      groupIDs:
      - "your-group-id"
      projectID: "your-project-id"

Kubernetes and ESO version

• Kubernetes version: v1.31.9
• External Secrets Operator: v0.18.0

Expected behavior

Group-level GitLab variables defined with “All (default)” as environment should be retrieved (it was the previous behavior before the fix for #3379) in addition to those defined for a specific the environment.

Screenshots

N/A

Additional context

• This behavior is breaking backward compatibility with common GitLab setups where group variables are used across environments.
• Possibly related to this logic in the GitLab provider after the fix: it might be filtering out variables with environment_scope == "*".
• A possible expected behavior would be: if environment is not defined in the SecretStore, retrieve both variables defined for "All (default)" and those for specific environments.