fix(sandbox-daemon): reject duplicate secondary repoName entries

[pedrofrxncx]

Bug found while auditing packages/sandbox/daemon-go/internal/config/ and internal/gitx/ for missing validation/error-handling gaps.

Failure scenario: git.repositories is a config patch surface reaching in from off-pod (the org's own client). paths.SecondaryRepoDir(repoDir, name) maps a repoName deterministically to one clone directory, but validateGit only validated each repoName's shape individually — never that it's unique across the array. Orchestrator.cloneSecondaryRepos (internal/setup/orchestrator.go) builds its full job list (one job per repository) before any directory exists to skip on, then fans every job out concurrently (secondaryCloneConcurrency = 4) via SpawnClone. Two entries with the same repoName therefore become two git clone processes racing to write the same directory at once — a corrupted checkout, not a clean rejection.

Fix: validateGit now tracks seen repoNames and rejects a duplicate at the same trust boundary where every other per-repo shape check already lives, before it ever reaches the orchestrator's fan-out.

Regression test: TestValidateGitRejectsDuplicateSecondaryRepoNames in validate_test.go — two repositories with the same repoName, asserts validateGit returns a rejection reason instead of "".

Reviewer command: cd packages/sandbox/daemon-go && go test ./internal/config/...

Local checks run: go test ./internal/config/... (green), gofmt -l on both touched files (clean), go vet ./internal/config/... (clean). Full CI (daemon-e2e, rust-checks etc.) validates the rest.

---

Summary by cubic

Rejects duplicate secondary repoName entries in git.repositories so two entries pointing to the same clone directory no longer race to clone concurrently. Previously, validateGit only checked each entry individually, so the orchestrator could launch two git clone processes into the same directory, corrupting the checkout. Now the validation rejects duplicates at the trust boundary before they reach the fan-out.

^{Written for commit 610c885. Summary will update on new commits.}

[pedrofrxncx]

Closing as stale: this PR sat past the bot's 48h merge window, main has moved on, and its CI results no longer reflect the current base. This is a housekeeping close, not a rejection of the change — if the underlying problem still exists, the bot will find it again and open a fresh, rebased PR.

[studio-bot:stale-close]