Drop OSVDB-derived OSV aliases from the rubygem data sources

[MGpromax]

Closes #2421

The rubysec advisory data references the defunct OSVDB database in its osvdb field, and both vulnerabilities/importers/ruby.py and vulnerabilities/pipelines/v2_importers/ruby_importer.py turned these into OSV-<number> aliases -- not public aliases, and a prefix collision with the modern OSV.dev namespace.

This PR:

• removes the osvdb -> OSV-... alias code from both importers (the OSVDB-*.yml files themselves were already skipped);
• updates the importer test fixture accordingly;
• adds data migration 0143_remove_rubygem_osvdb_aliases deleting previously imported ones from both the Alias (v1) and AdvisoryAlias (v2) tables. The regex ^OSV-\d+$ matches only the OSVDB-derived single-hyphen form, so genuine OSV.dev identifiers (OSV-<year>-<number>) are preserved.

Testing: the ruby importer tests pass (7 passed; the 4 errors in test_ruby_advisories_per_file are TransactionManagementErrors that occur identically on a clean checkout in my sqlite environment and are unrelated). manage.py migrate --plan includes the new migration cleanly.

[ziadhany]

@MGpromax, first of all, we need to identify where the data is coming from and how it is being imported.

We can start by searching for the OSV aliases in the VulnerableCode database using SQL and then trace them back to the corresponding importer.

Alternatively, we can search in:
https://github.com/aboutcode-data/staging-security-advisories

This should help us identify the original data source and the import pipelines responsible for adding the data to VulnerableCode.

Once we identify the relevant importers, we should update them accordingly.

Note: We are going to drop the old importers, so please focus on the importers under pipelines/v2_importers/*.

[Shriprasad-P]

Review

PR: Drop OSVDB-derived OSV aliases from the rubygem data sources

Touched: vulnerabilities/importers/ruby.py, vulnerabilities/migrations/0143_remove_rubygem_osvdb_aliases.py, vulnerabilities/pipelines/v2_importers/ruby_importer.py, vulnerabilities/tests/test_data/ruby/CVE-2010-1330-expected.json

• Addresses a concrete correctness/reliability issue based on the title and diff.
• Includes or touches tests — good for locking the behavior.
• Size looks manageable (+44/-7).

Commenting as a drive-by reviewer after reading the diff. Happy to look again if maintainers want a deeper pass on a specific file.