[bug] Azure DevOps connection schema rejects project and repo names containing spaces

[TheS1ngularity]

Describe the bug

Sourcebot’s Azure DevOps connection supports projects and repos, but the current config schema rejects valid Azure DevOps names when the project or repository contains spaces.

Because of that, we cannot use the native Azure DevOps projects / repos configuration for a number of repositories and have to fall back to generic git clone URLs instead.

Expected behavior:
Sourcebot should allow valid Azure DevOps project and repository names with spaces in projects and repos, or provide a documented supported encoding/identifier format for those values.

To reproduce

1. Create a Sourcebot config with an Azure DevOps cloud connection.
2. Use token.env for the PAT, for example:
   • type: "azuredevops"
   • deploymentType: "cloud"
   • url: "https://dev.azure.com"
   • token: { "env": "PAT_TOKEN" }
3. Add a project or repo entry containing spaces, for example:
   • projects: ["user/My Project"]
     or
   • repos: ["user/My Project""]
4. Start Sourcebot.

Actual result:
The config is rejected during validation because the schema patterns for Azure DevOps projects / repos do not allow spaces.

Expected result:
The config should accept valid Azure DevOps names with spaces and Sourcebot should sync those repositories through the native Azure DevOps integration.

Sourcebot deployment information

Sourcebot version (e.g. v3.0.1): v4.17.0
Deployment method: Docker Compose
Code host: Azure DevOps Cloud
Config schema: v3

Additional information

Relevant details:

• Azure DevOps supports project and repository names with spaces.
• Sourcebot’s Azure DevOps schema currently appears to restrict projects and repos to patterns that allow only [\w.-], which excludes spaces.
• We were able to work around this by keeping those repositories as generic git connections and templating the PAT into the clone URLs via an environment variable before Sourcebot starts.
• That workaround works, but it bypasses the native Azure DevOps connection path.

This seems related to the Azure DevOps schema/validation layer rather than the underlying host capability.