Can these services not use the same fallback mechanism that already exists for non-passkey logins? i.e. an email with a 1-time code or similar. Yes that somewhat defeats the purpose of passkeys but that option is going to exist for a long time regardless of passkey adoption.
If you don't want to downgrade security, how about requiring confirmation from another session that is already logged in using a passkey? e.g. You try to log in on PC2. A prompt appears with something like "confirm this login from [PC1, etc.]". You log in on PC1 using your passkey. The service recognizes that the login id definitely you, or at least someone in possession of your physical device and login method for that device. Therefore, it then allows PC2 to register a new passkey. Kinda similar to how google confirms new logins by sending a notification to your phone.
That could work, but then the service needs to implement complex non standardized authentication mechanism outside of Passkeys. You will have 14 different services with 15 different options. I don't think that's really user-friendly.
Also it could be vulnerable to MFA fatigue attack, if people would constantly get new "confirm this login" popups, they would press anything to make it go away.
So you would need something that is explicitly initialized from a trusted session, then you need something to connect the trusted session to the new login. If you want that to be user friendly you need some short codes and can't rely on QR code / Bluetooth, or two-way interaction. And that brings up the phishing / MitM attacks again.