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

## 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 (https://github.com/aws-samples/sample-collaborative-ai-dlc/pull/256#issuecomment-4679438815)

Start with the DELETE /projects/{id}/repos and PUT {gitRepo} endpoints, then trace how running Sprints and branch work reference repositories. Review the orchestrator's env.gitRepos and trigger_pr_creation behavior, along with PR #256's M5 finding. Define the in-flight semantics, implement the rejection or force behavior, and document the API outcome.

Written by the indexing model from the issue text.