Your suspicion is right and the log line is the whole story.
What changed. A datasource that used to be built in has been moved to being a separately distributed plugin. Functionally it is the same thing. Operationally it is completely different: something that shipped inside the package now has to be fetched, and on first start after the upgrade the server tries to fetch it.
That is why the two things you found look contradictory but are not. The CLI lists the plugin because the old bundled copy is still on disk from before the upgrade. The running server does not recognise it, because it now expects it in the location and shape that installed plugins use. So it is present and unusable at the same time, and "no installed plugin with that id" is literally accurate from where the server is standing.
Why disabling auto-update did not help. Auto-update governs upgrading plugins you have. This is a first install of something the server now considers missing, which is a different code path and is not what that setting controls. Worth knowing generally: "do not update" and "do not install" are usually separate switches, and operators reach for the first one expecting it to cover both.
Why your provisioned datasources broke too. Provisioning creates the datasource record, and the record names a plugin that has to exist for it to resolve. No plugin, no resolution, regardless of how the record got there. Provisioning is not a substitute for the plugin being installed and never was — it simply used to be, because the plugin was always there.
So nothing on your side is misconfigured. The upgrade added a dependency on network access that your server is designed not to have.