feat: Support multiple upstream repos under a single security tracker

### What should happen

A single tracker (one security@ list, one private tracking repo) should be able to handle findings across a family of separate upstream repos, routing each finding to the right repo for scope detection, fix targeting, and release tracking.

### Why

Some ASF projects are structured as a family of separate upstream repos that share a single security mailing list and operate as one team. Apache Iceberg, for example, spans Java, Python, Go, Rust, C++, and Terraform implementations as sub-projects in distinct repos.

Today `scope_detection.labels` and a single `upstream_repo` assume one upstream per tracker, so the only ways to adopt Magpie for such a project are to run a separate tracker + mailing list per sub-project (real infra overhead for a team that operates as one), or to give each sub-project its own `project.md`. But with a shared issue list, an un-routed finding can quietly fall through the per-scope triage filters and get lost.

We'd rather close the gap if a single multi-repo tracker is a direction you're open to.

### Which layer

Project template (`projects/_template/`)

### Boundary conditions (optional)

- A finding that matches no sub-project should still be visible, not silently dropped from scoped triage sweeps (today it lands as `needs triage` but is invisible to `triage scope:`).
- Backward compatibility: a project with no sub-projects declared should behave exactly as today, with upstream_repo as the single implicit sub-project.

### Out of scope (optional)

The exceptional private-PR fallback ([Step 9](https://github.com/apache/airflow-steward/blob/main/docs/security/process.md#step-9--open-a-private-pr-exceptional-cases)), where the base branch is the tracker's mirror of the upstream. Multi-repo setup affects that path too, but it's a separate, lower-frequency follow-on we'd rather not fold into this discussion.

### References (optional)

_No response_