feat: Support multiple upstream repos under a single security tracker #444

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:<label>).
• 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), 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