[lsmith77]

Closes #293.

Many projects live on more than one forge, for example GitHub mirrored to a self-hosted Forgejo such as code.overheid.nl. A mirror carries the same publiccode.yml with a url pointing elsewhere, so parsers skip it as a technical fork, and a project has no way to say the mirror is its own. This PR lets the project declare its mirrors.

Authority stays with url, as @bfabio asked in the issue: mirrors is read only from the file at url, and a listed repository counts only if its own file points back. The key is optional; parsers that do not know it see a technical fork, as today.

What a listing means. mirrors tells parsers that a repository is the project's own copy rather than a technical fork, and records that the project endorses it. It does not say the mirror is in sync. A mirror hours or even days behind is normal; one that stays behind for long should be removed, and one that is ahead of url has diverged. Checking that means comparing the repositories themselves, which is beyond publiccode.yml and its parsers.

Security

The main risk is identity takeover: catalogs attach a project's history to its url.

Attack	Mitigation
A clone, or a forged or stale copy of the file, claims mirror status.	mirrors counts only in the file at url.
A project lists someone else's repository as its mirror.	The listed repository's own file must point back. Repositories without a publiccode.yml cannot be claimed.
A URL is spelled differently (case, .git, trailing slash) to slip past a comparison.	URLs are compared after normalising.
A file lists thousands of URLs or internal addresses to abuse crawlers (SSRF).	Usual fetch restrictions apply, and parsers may check only the first entries.
Someone takes over a lapsed mirror location and publishes a file pointing back.	Authors must remove locations they no longer control or trust. Deprecated mirrors count only if confirmed while reachable, and their code is never offered as the project's.

Not covered: whether a mirror serves the same code (see above; comparing commit hashes checks that, as @bfabio noted), and compromise of the repository at url itself, which every key already trusts.

Edge cases

• A mirror being set up or lagging behind may not point back yet. Parsers keep existing entries and check again later; waiting periods and manual intervention are catalog policy.
• A repository renamed on its forge keeps working: parsers follow redirects before comparing, so it is not mistaken for a fork of itself.
• Internal development with a public read-only copy: url is the public repository, where the software is published. The internal instance is not listed, since nobody outside could check it and listing it would publish internal host names.
• A decommissioned mirror is marked deprecated, so references still resolve. It counts only if a parser confirmed it while it was reachable, and that confirmation outlives it. Removing the entry revokes it.

Trade-offs

• Recognising a mirror costs a fetch of the file at url. A failed fetch changes nothing; the parser keeps the last known result and retries. A repository never confirmed as a mirror is a technical fork, as today.
• Deprecated mirrors rely on crawl history, which catalogs keep. Policy questions are left to them, as organisation/uri already does ("depends on the implementation and policies of the platform consuming the file").

Further adversarial reading is very welcome: these cases came from several rounds of trying to break the rules, and there are likely more.

Out of scope: forge migrations, where url itself changes; describing what a mirror is for (backup, development, contributions); multi-repository projects (#169).

Rationale: Sanctioned Mirror Declarations.

[vercel]

@lsmith77 is attempting to deploy a commit to the bfabio's projects Team on Vercel.

A member of the Team first needs to authorize it.