Apparently, InstantCommons already has all the repository information configured (according to T190576 this is what gets configured):

>>> $wgForeignFileRepos
=> [
     [
       "class" => "ForeignAPIRepo",
       "name" => "wikimediacommons",
       "apibase" => "https://commons.wikimedia.org/w/api.php",
       "url" => "https://upload.wikimedia.org/wikipedia/commons",
       "thumbUrl" => "https://upload.wikimedia.org/wikipedia/commons/thumb",
       "hashLevels" => 2,
       "transformVia404" => true,
       "fetchDescription" => true,
       "descriptionCacheExpiry" => 43200,
       "apiThumbCacheExpiry" => 0,
       "directory" => (takes the $wgUploadDirectory value)
       "backend" => "wikimediacommons-backend",
     ],
   ]

When a page contains images not in the local repository, it should perform only one request to the foreign repo with action=query&prop=imageinfo and the list of file titles that are not found on the local repo, to get image dimensions and other possible metadata, but not thumbnail URLs. It has thumbUrl in the configuration, and MediaWiki should be able to infer the URL of any thumbnail.

You cannot reliably infer thumbnail URLs, in some edge cases they depend on what MediaHandler::mustRender() would return for the file, and that cannot be determined from metadata alone. Also thumbUrl doesn't really tell you the thumbnail URL structure.

I think $wgForeignFileRepos has all the information to determine the thumbnail URL structure. It would need to configure something like a LocalFileRepo but with the remote url. hashLevels would be used to generate the hash levels, and thumbUrl would be used for thumbnails. This should work for InstantCommons. If other repositories have some special handling, they would need to subclass ForeignAPIRepo.

You're right about MediaHandler::mustRender(). This can be a flag that may be added to the results of action=query&prop=imageinfo to allow this special handling.

You'd have to deal with changing the file extension for things like SVG, with max filename length, and who knows what else. Seems like a ton of effort just to work around the API not being able to handle multiple sizes. And images are not even guaranteed to exist on the remote repo in the given size until you query them.