Bug in Registrator.jl: New package PR (for SimSpread.jl) contained two versions, one of which is not installable (and might not have ever been installable)

I believe that I've identified a bug in Registrator.jl that is now causing problems when trying to change a package URL. The purpose of opening this issue is three-fold:
1. Figure out how to help the package author in this specific situation.
2. Diagnose and fix the bug in Registrator.jl.
3. Add checks to AutoMerge to catch this kind of issue in the future.

The specific situation here concerns the SimSpread.jl package (located in the registry at [`S/SimSpread`](https://github.com/JuliaRegistries/General/tree/master/S/SimSpread)).

The SimSpread package was originally registered in October 2023; here is the new package PR: #94323

Look at the diff for #94323: https://github.com/JuliaRegistries/General/pull/94323/files

Specifically, look at the diff for `S/SimSpread/Versions.toml` file:

https://github.com/JuliaRegistries/General/blob/7aa782c610af0848959b3bbc9014b6a1c265c5be/S/SimSpread/Versions.toml#L1-L5

Somehow, Registrator.jl put two versions (1.0.2 and 1.0.3) into #94323. This (to me) seems like a clear bug. A single PR should only register a single version; this should hold true whether the PR is a new package PR or a new version PR.

Currently AutoMerge is not set up to detect this kind of situation; AutoMerge assumes that Registrator.jl generates PRs in certain ways, with "one version per PR" being one of those assumptions. So on https://github.com/JuliaRegistries/General/pull/94323, I'm guessing that AutoMerge only ran its checks on 1.0.3, and AFAICT (from the AutoMerge comment) those checks passed, and the PR was AutoMerged.

Unfortunately, 1.0.2 was never checked by AutoMerge. And, per the author (see https://github.com/JuliaRegistries/General/pull/145696#issuecomment-3774666032), there is no commit in the repo that corresponds to 1.0.2.

The author is now transferring the repo to an org (#145696), and the Treecheck is failing, because the "new repo" doesn't contain the tree for 1.0.2.

Some questions:
1. What do we do in the specific situation? Do we delete 1.0.2 from the registry? Historically, we never delete registered versions, except in very rare situations. However, this might be one of those very exceptional situations. It's not even clear to me if 1.0.2 has ever been installable.
2. Where is the bug in Registrator.jl, and how do we fix it?
3. What kind of checks can we add to AutoMerge to detect this kind of issue before merging?

Start with the SimSpread Versions.toml diff in PR #94323 and the related Treecheck failure in #145696. Then trace how Registrator.jl produced the two versions and how AutoMerge checked the PR; done means resolving the 1.0.2 situation, identifying the registration bug, and defining checks that prevent multiple or unverified versions.

Written by the indexing model from the issue text.