There are hardware for that called hardware security modules, but yeah I definitely wouldn't trust Twitter's implementation - especially because they probably just need the auth team to tell the HSM that the user logged in when they didn't to get that key
A proper implementation would use multiple security measures and require a reset (delete) of certain private account data before the account access can be reset, otherwise the user's password would be needed (for key derivation) or some other secret held by the user's devices (in the TPM chip or equivalent)
Bluesky federates across different layers, it's modular, it doesn't have a comparable same-layer federation. It is fully interoperable, just not by the method you're used to.
You can host your own partial appview now (caching and indexing your and your friends' comment), and multiple people have managed to run their own relays for cheap (caching most of the posts in the network), and you can pull the rest of data you need to browse from the other relays and use the service as usual. You can run your own moderation labeler, use your own app, just your own account, etc...
Just look at the interoperable blacksky project by a bunch of black devs making their own infrastructure for accounts and moderation, etc.
To be non federated, all you have to do is not announce your server and not accept arbitrary connections
Due to content addressing, limited federation isn't really a thing by the usual definition. You can filter content from any PDS you don't like, but can't really control who can see already public posts