Edge case with package updates endpoint and "transferred" packages

In the JSON returned by /api/updates/, both the "old" and the "new" package map to the same release ID, but the release only exists for the "new" package, so hitting https://content.luanti.org/packages/{author}/{pkgname}/releases/{release_id}/download/ gives a 404 for one of them.

For example there is "Pyrollo/display_modpack": 36909, "mt-mods/display_modpack": 36909 in the lookup table, and https://content.luanti.org/packages/Pyrollo/display_modpack/releases/36909/download/ is a 404 whereas https://content.luanti.org/packages/mt-mods/display_modpack/releases/36909/download/ succeeds.

Maybe redirect the former to the latter?

If there's some internal reason this is useful, maybe add a small note on https://content.luanti.org/help/api/#packages that documents this?

(Background: I wrote a script to fetch the latest versions of all packages on CDB and I noticed that it skipped a few packages due to this. Ultimately I don't care because these are precisely outdated packages.)

Start by tracing the implementation of the /api/updates/ endpoint and how transferred packages are represented in its lookup table. Reproduce the Pyrollo/display_modpack and mt-mods/display_modpack download URLs, then make the old-package result resolve correctly or document the behavior at https://content.luanti.org/help/api/#packages; verify both update data and downloads.