multi-repo: removing a repo (or changing primary) has no in-flight sprint guard

[eipasteur]

Problem

DELETE /projects/{id}/repos and set-primary (PUT {gitRepo}) succeed even while a construction sprint is actively running against that repo. Consequences:

• the running orchestrator's env.gitRepos snapshot still contains the removed repo → trigger_pr_creation invokes create-pr for a repo the project no longer references (PR created for a detached repo, or a confusing failedRepos entry)
• removing the LAST repo mid-sprint leaves gitRepo: '' while agents are cloning/pushing
• a primary change mid-sprint flips role labels under the orchestrator

PR #256 added a client-side confirmation dialog with warnings (primary auto-promotion, last-repo), but there is no server-side guard.

Proposal

• On repo DELETE / primary change: check for Sprints in a running phase whose branch work references the repo; reject with 409 + actionable message (or require a force flag)
• Define semantics for in-flight work on a removed repo (abandon? finish the sprint with the old snapshot?) — document the choice in the API

Refs: PR #256 review finding M5 (#256 (comment))