I haven't worked with Fedify before, but what I'm talking about is the difference between a service that has a "translation layer" between their own internal data model and ActivityPub, and a server that actually stores full ActivityPub object's in the user's inbox and outbox, and displays them unchanged to clients. 90% of deployed ActivityPub applications—like yours!—are the former, not the latter.
A true "ActivityPub server" is almost as simple as a Bluesky PDS—all it's responsible for is 1) storing blobs of data, 2) fanning out subscriptions and 3) collecting incoming data for you to view. In the original way ActivityPub was designed, all of the actual data presentation layers—Mastodon, PeerTube, Pixelfed—were designed to be specialized clients that could communicate with the user's generic server. However, the first popular implementations cut out the client-to-server part of the protocol, so now we're stuck in a place where everyone thinks ActivityPub means you need a separate identity for every client application.
So, what I would recommend for your own username/password site is implementing an ActivityPub client, and recommending that users use it to connect to a third-party ActivityPub server. That way, the user owns the data, and they simply use your service to get access to (filtered version of) it.
Unfortunately, since this is a less implemented part of the protocol, the client APIs necessary to make this a reality haven't seen much development. And you're facing an uphill battle for user adoption. In practice, users don't seem to mind having separate accounts and identities for different clients. It reminds me a bit of the "key management problem" in e2e cryptography. Having a stable cryptographic identity is doable if you're technically minded, but most people just muddle along and don't really care about it that much—they create new keys every time they get a new laptop instead of trying to figure out cross-signing, and everything works itself out more or less fine.