Like other commenters have said, start by asking the upstream developer (whether that's by sending a message with a link to the fork or by sending a mega-PR that says you don't expect it to be merged as-is in the description). They should be the best judge of how they'd prefer to handle it. The thing I'd add is that you should try to avoid taking it personally if their preferred approach isn't one you think is a good idea. Sometimes good fixes end up never merged because of disagreements becoming too heated even if everyone's basically on the same page about the fox being good. There's also a decent chance that your refactors are things the upstream developer explicitly doesn't want and would otherwise have done them themselves and implemented the same fix, too, or they don't agree that your fix is good enough. They won't want to be on the hook for maintaining contributions that use approaches and code style that they don't like, and that's okay. They also might know something you don't about their project that would make something that's obviously a good idea to you obviously a bad idea to them.

Basically, just try and remember that if it's a hobby project, it makes progress when the maintainer is having a good time, and gets abandoned when they're not anymore, so try and avoid making a mess and having arguments when they're the one that'll have to deal with any fallout from any mistakes.

The general rule of thumb is, if a single PR changes lots of things then it won't be accepted.

I'd suggest breaking it into multiple PRs and possibly reaching out to someone on the core team to explain what you were trying to do and how you've done it kinda like RFC. Ideally this would've be done before you started with a major change but still.

I see you also mentioned original devs are no longer active. In that case you can send PRs but don't expect them to get merged but instead if you are still using it, try to update and fix other things as you see fit and people will see it and start using your repo and if at any time original devs comeback maybe they can official handover project to you or accept all your PRs. And this is totally OK as long as you are not breaking any license original devs had, that's what forks are for. If you want you can rename and do rebranding but that is not necessary unless original devs had trademarked the logs and stuff and that original repo is completely dead.

Create a PR and describe the situation. Ask if they'll accept the PR as-is or if they'd accept the refactors separately.

Give it to the dev, and explain the situation. Let them know it seems too big/complex of a PR, but you're willing to make additional changes, or break up PR to make it more palatable for merging. It's in the dev's hands after that.

I don't think you should release your own fork without at least trying to work with the original project.

Make sure all your commits have detailed commit messages so that the dev can follow what you were doing (upgrading deps, refactor because xyz, etc.) Don't just record what was changed, explain why it was changed.

anyway that's what I would do.

If you can, fork it again but this time only fix the one bug with minimal changes and submit that as a PR. Then ask the maintainer about submitting more to fix the other bugs, and doing some refactoring.

I'd say ask the original developer directly. Getting your changes merged upstream should be the preferred option for you, the original dev and the users. If everything goes right, you both could figure out a way to do this, maybe by re-introducing your refactorings and fixes one by one in smaller pull requests. Maybe you could become a maintainer in the process and support the original dev long term so everybody wins.

If the original developer doesn't respond or declines you could think about bringing your own fork forward. Think about the consequences though, the original dev might get frustrated by a competing fork and abandon the project completely. The users on the other hand might be confused or insecure about which version to choose. Your fork must offer a lot for them to jump ship and switch.

Generally I'd say open source is about working together, not against one another, so just shoot them a message and see where it goes.