Validate GitRepositoryName so a name cannot reshape a request path

[matt-edmondson]

GitRepositoryName carries only [HasNonWhitespaceContent], so a name containing /, ?, or .. passes validation.

The two providers handle that inconsistently. AzureDevOpsProvider runs Uri.EscapeDataString over the organization, project, and repository before building a URL. GitHubProvider hands the raw value to Octokit, which formats it into a relative URI without escaping. A name containing a separator can therefore reshape the request path.

This is not a vulnerability, because the caller is the trusting party and the blast radius is a request to a different URL under the caller's own credentials. It is an inconsistency worth closing, and a validated type would fix both sites at the source rather than at each use.

Related to the containment guard added in #80, which handles the same class of input for local paths.

[matt-edmondson]

Triage

Priority: Medium Effort: Small

What needs to be done: GitRepositoryName only checks [HasNonWhitespaceContent], so a name containing /, ?, or .. passes validation and can reshape the request path — inconsistently handled today (Azure DevOps escapes with Uri.EscapeDataString, GitHub hands the raw value to Octokit unescaped).

Note on severity: the issue body itself explicitly assesses this as not a vulnerability — the caller is the trusting party and the worst case is a same-credentials request to an unintended URL under the caller's own control, not cross-trust-boundary injection. So this is a robustness/consistency fix rather than a security vulnerability; I'm not elevating it to Critical/High on that basis, though it's still worth closing at the source via a validated type.

Suggested next steps / acceptance criteria:

• Add validation to GitRepositoryName rejecting path separators, ?, and .. segments.
• Remove the per-site escaping/no-escaping inconsistency now that the type itself guarantees a safe value.
• Add tests for rejected and accepted names.

Blockers / dependencies: None identified. Related to the containment guard added for local paths in #80/#82 (same class of "untrusted string reshapes a path" concern).

---

Generated by Claude Code