Records written before #5592 still serve url-encoded PURL separators

**Describe the bug**

#5592 fixed the generator, but the records stored while the bug was live were never regenerated. They still serve `%2F` today, six weeks later.

**To Reproduce**

```
curl -s https://api.osv.dev/v1/vulns/DRUPAL-CONTRIB-2026-045 | jq '.affected[].package.purl'
"pkg:composer/drupal%2Fmothermayi"

curl -s https://api.osv.dev/v1/vulns/GHSA-p2fr-6hmx-4528 | jq '.affected[].package.purl'
"pkg:npm/%40better-auth%2Foauth-provider"
```

**Expected behaviour**

`pkg:composer/drupal/mothermayi` and `pkg:npm/%40better-auth/oauth-provider`, same as #5592 produces for new records.

**Additional context**

Counted on the `all.zip` exports of 2026-08-22, distinct records with an encoded separator in the coordinates:

```
npm 1011
Packagist 424
SwiftURL 1
```

*1436* records, `modified` between 2026-05-19 and 2026-08-13.

It doesn't clear itself either. 14 of them were modified after #5592 shipped and still carry the old purl, e.g. GHSA-qc4c-hrmc-4f78 on 2026-08-13 with `pkg:composer/admidio%2Fadmidio`.

Still breaking the use case from #5590: 40 DRUPAL-CONTRIB records remain unmatchable by purl.

Review the behavior introduced by #5592, then query the two example API endpoints and inspect the all.zip export counts to identify how stored records are refreshed. Done means the affected historical records no longer encode PURL separators, including the remaining DRUPAL-CONTRIB cases, while newly generated records retain the corrected format.

Written by the indexing model from the issue text.