Protect against cross-instance redirects #488

Supporting multiple instances of a forge opens us up to a potentially brand new kind of move.

While moves within a forge are supported (github,gitlab etc all presumably set up redirects for if a repo is moved to a different org), self-hostable forges present a unique challenge:

If a company is acquired, or a homelabber changes domain names, their instance at git.abc.com could move to git.xyz.com. The redirect would be set up via a standalone proxy of some kind (external to the forge).

While we might be able to take this as a sign that the repo identifier namespacing is the same across both forges (because the sysadmin would likely be setting up a deliberate reirect for a reason), its not a guarantee (the redirect target can be anything).

We should detect these kinds of cross-instance moves as part of the move detection logic so we dont create issues.

It also may be nice to have a mechanism to validate whether a forge is the same or not. Couple ways to do this:

1. get lucky and learn that forge instances have their own unique IDs by convention
2. validate every object identified in our db (issue numbers, PR numbers, repo ids etc) are present on the new instance (maybe with user confirmation)
3. dont bother checking and force it to be set up as a new forge (user would have to recollect potentially duplicate data)