Based on the above comment, it seems that DMTN-027 (Renaming an LSST git repository) may require an additional check:
- ensure that no changes in the old package have been introduced after the fork.
and for changes, I am not only referring to code changes, that are quite unlikely to happen but tags.
In this case in fact, during the process, two tags have been added in the old one and have not been propagated to the new one.
I can't be sure, but if this were the case, the official-release job 31 yesterday would not have failed, because of the correct v19.0.0.rc1 tag was found in the new lsst/dax_apdb, and the correct 19.0.0 would have been tagged in the right place.
Said that I am quite reluctant to suggest a change in the tooling. If the renaming of the package is done properly, there should be no problems. In case of a missing tag, the workaround is trivial.