This is an issue I spotted while triaging MDL-84075. It's definitely an LTI 1.3 problem but probably also affects 1.1 links the same way (I didn't specifically check that yet though).

To replicate:

1. Create a site-level 1.3 tool in Site A.
2. Create a course in site A
3. Using deep linking, create a link to the tool in the course
4. Backup the course, using "Jump to final step"
5. Download the backup mbz
6. Go to Site B
7. Create a site level tool configuration for the same tool as was used in Site A
8. Now, restore the backup into a new course. You should see the single LTI link activity
9. Now, launch the activity. The tool should launch fine (this just confirms that the domain matching is working as we'd expect).
10. Edit the activity settings
    Expected: You don't see any warning about using a manually configured tool instance
    Actual: You DO see any warning about using a manually configured tool instance

Brief summary of the problem:
Basically, domain matching is represented two ways:

1. In the non-restore case, where a link uses a URL that matched a tool in the same site. In this case, the typeid IS set and links to a (likely hidden) site level tool. The important part is that typeid is set. We have already handled this case. Okay, moving on...
2. In the restore case, the link has a null typeid, but can still domain match a site level tool in the restored site (that's how the launch works, after all). We're not picking this up during the mod form loading, however, and incorrectly report it as manually configured instance.

Solutions:

1. Extend the form logic to check for links having null typeid but which domain match a site-level tool. This should prevent the warning and present the link as if it were explicitly linked to the site-level tool in the restore site.