This extra line of code for the InstalledViewModel version of the tests is an artifact of what seems to me a funny disconnect between the unit tests and the 'in vitro' code.  When creating a bare InstalledViewModel, nothing ever pings ExtensionManager to pull from the registry, so the view will never know if any updates are available.  But when booting up the Installed tab in the real UI, the dialog always blocks on downloadRegistry() first, so updates are reflected in the Installed tab without having to explicitly visit the Available tab first.

The other unit tests get around this by loading the entire ExtensionManager JSON state as a blob, which is a little odd to me since that unified/merged blob represents internal state and doesn't resemble either of the inputs it normally receives (normally it gets installed & registry separately, merging them itself).  These tests feed it two pieces separately, each of which resemble real inputs.  Seemed cleaner / more realistic to me; hope that's ok.