It all boils down to wanting some sort of sync function either DIY or otherwise that includes hosts and SSH keys
I don't know of any free terminal emulator that runs on all those platforms. Much less one that is a combination ssh client and has host bookmarks. There are gonna be some pretty fundamental UI differences on desktop and mobile platforms.
Alacritty
That's not an ssh client and doesn't run on Android.
I suppose you can use openssh. I think that that runs on all those platforms -- use it with Termux in Android. But while it is an ssh client, it's not a terminal emulator; you'd run it in a terminal emulator on each platform. And while you can synchronize the files it uses with external software, it itself doesn't sync.
Same story for Dropbear.
I don't know what you're referring to when it comes to syncing keys, public or private.
You don't want to move your private keys around. Those are supposed to be per-host, so that if one gets compromised you can deauthorize just that host.
SSH itself will pull over remote public SSH keys the first time it contacts a host. Normally, people don't distribute those outside of that.
If you're worried about falling prey to a man-in-the-middle attack if the first use of a host is on an untrusted network and don't want to make use of ssh's key fingerprint verification, then I guess you could maybe make an argument for syncing a list of public keys. For openssh, you'd need to have something that can bidirectionally synchronize and merge changes in ~/.ssh/known_hosts, which is a text file. It's not the normal mode of use, though, and it means that compromise of any of your hosts running the ssh client will compromise the others in terms of trusting a given key to identify a remote host. I would not do that, myself.
And if your synchronization system permits for overwriting arbitrary files other than ~/.ssh/known_hosts, like ~/.ssh/authorized_keys, then you've got yourself a rather-larger security issue; compromise of one client can directly compromise the others to the point of allowing remote shell access to it.
X.509 certificates -- what most non-ssh programs use for key distribution -- don't have the issue of public key distribution on a per-host basis. They all trust a cerificate authority to sign certs. It looks like some implementations of ssh support X.509 certs. I suppose you could look into setting that up. Create a certificate authority, have all clients trust the CA, provide each ssh server with a signed certificate. That's going to be an exotic setup. But you won't have the man-in-the-middle vulnerability.
You can also set up a Kerberos environment, which looks like a more-common configuration for SSH than X.509. You are gonna need to be able to access the KDC from all the involved machines, though. That'll also avoid the man-in-the-middle risk; Kerberos relies on the fact that the password is a shared secret known to the KDC and client to bootstrap trust. That'd still be a kind of an unusual setup. This is pretty elaborate, though.
If you just want a list of bookmarked hosts to click on, all this is probably overkill. You don't need to synchronize keys. Any system that permits synchronizing a text file would do, as long as you can view that file in software that permits opening ssh: URLs in your terminal program. Like, have a synchronized Markdown file or something.