The best comparison here is email. So Google created an email service and serve ads with their email. This, of course, has no effect on anyone not using Google's email service and since Google still follows the standards protocols for mail servers to talk to each other it doesn't even impact their ability to communicate with other remail servers or vice versa.

The same idea works with Mastodon and Lemmy - there isn't one centralized service that can be bought, the same way you can't buy "email" or "the web".

The absolute worst case would be Musk buying the rights to the server code and changing the license for all future versions to something closed. At which point, everyone else just forks the last open version and builds on it from there. So long as neither changes the underlying protocol this has no real effect on end users. If one of them does, then it creates a split between Muskodon and whatever the new fork is called akin to both sides defederating each other.

The instances sync data only as needed - for example, if a user on a specific instance is following someone on another instance, and that someone posts something. Fetching and storing data from the entire Fediverse would require an absolutely enormous amount of bandwidth and storage, much more than most people will ever be able to afford and maintain :) (This is also why instances often purge old cached data - to reclaim storage space that is unlikely to be taken by useful data, per the nature of minuteness of social networking, and if you ever need a deleted resource, it can just be requested and synced back up to your instance, as long as it's still available on the original one.)

As the end user, you should be aware that this synced data may, and most likely will at some point (not many instances achieve absolute 100% uptime, after all), get incomplete - especially if you're using a smaller instance. When browsing user profiles, it is generally a good idea to look up their profile on their own instance, as it is guaranteed to have all of their data.

Also note that my explanation regarding "frontends" is oversimplified and technically inaccurate: a "frontend" is the user interface part on top of the software that implements the protocol. This, basically, means that you don't have to stick with whatever UI your instance offers - there are other web and native clients that will talk to your (Mastodon, Pleroma, Misskey, whatever they come to support) instance, and your instance will still handle all things ActivityPub, such as fetching data from other instances to it and vice versa.