Scan creates duplicate releases for the ones migrated from Drupal 7

Problem/Motivation

The drupal.org release scan decides whether a release is new by looking up its download link. Drupal 7 stored those links as http://ftp.drupal.org/... and the migration copies them verbatim, while the scan on 3.0.x builds https://ftp.drupal.org/... links. So after the migration no migrated release ever matches. The first scan on the new site reads about a day of rows before the last sync time (the deliberate overlap from Drupal 7) and creates a second release entity for each of them, which then gets parsed a second time. A first scan without a seeded sync time would do this for every release ever published.

Proposed resolution

Match existing releases by project and version instead of the link. Versions are unique within a drupal.org project, and the match no longer depends on the link scheme. Add a composite index on project and version to the release storage schema, as the scan runs the lookup per row.

Also document in the site runbook that the release scan state has to be seeded from the Drupal 7 l10n_drupal_rest_last_sync variable after the migration, both keep a Unix timestamp, so the first scan starts where Drupal 7 stopped.

Test: kernel test with a release stored the migrated way (http link), then a scan of the fixture release list that contains the same release, asserting it is kept and only the other releases get created. Drupal 7 has no counterpart, it always writes http links itself.

LLM disclosure

LLM was used to find, diagnose explain and fix this issue. With human review.