How to combine two completely different git repositories with 90% of the common base, so that the private fork can be easily updated with commits from the main repository?

Question

git

Good afternoon. I warn you that there is a lot to read, but everything is on point.
There is the following:
a.) ORIGINAL_GITHUB_REPO is a product repository with 14000 commits that is still being developed. From this ORIGINAL_GITHUB_REPO I need to update my MY_GIT_REPO. But about it below, now you will understand.
b.) SVN_FORK_REPO is an SVN repository created in 2013 by one person who sold an extended version of ORIGINAL_GITHUB_REPO (i.e., based on this code base, he added his changes and features there).
c.) We used this SVN_FORK_REPO, we created a GIT repository for it, because it was more convenient to work with GIT, and not with SVN, and let's call it MY_GIT_REPO.
It turned out something like this:
MY_GIT_REPO/master -> SVN Repository from SVN_FORK_REPO - stored as a branch that when updates appear, I update (svn update), and then go to the branch below and merge the changes, and correct the problems a little. And this laugh was used for years, until the developer of SVN_FORK_REPO dumped and threw everyone.
MY_GIT_REPO/development -> already here I make all my changes, as updates appear (a bunch of commits merged by the developer from ORIGINAL_GITHUB_REPO into a single commit to keep the product up to date, once a month he updated his product like this. That is, he took as - then merged the changes on my side, checked that everything was compiled and dropped a bunch of commits from ORIGINAL_GITHUB_REPO to our SVN repository, from where we already took the changes using SVN update in the master branch (yes, yes, you understood correctly, when initializing .svn was not touched, and it is stored and fully working in the master branch.) So it turns out that now in this SVN repository r164, which corresponds to r13664 but already in the git.
Everything would be fine, but nothing, until one fine moment the developer of SVN_FORK_REPO dumped and updates of his SVN repository with changes from ORIGINAL_GITHUB_REPO stopped. It's been about 6 months and I need to update the product from ORIGINAL_GITHUB_REPO. Here I have already lost weight, and I do not know what to do.
How I did:
1. I took the MY_GIT_REPO branch and looked at the approximate date of the last changes from SVN_FORK_REPO, then looked for commits that correspond to the changes already in ORIGINAL_GITHUB_REPO, and went to the github commit, added .diff at the end, received a patch, and applied it to my code, solved it when conflicts appeared by their hands. But this was until the difference was not very large (the lag behind HEAD was no more than 10-20 commits). Now the backlog is about 300 commits, and somehow these commits in ORIGINAL_GITHUB_REPO need to be transferred to MY_GIT_REPO, and I don’t know how.
Actually the question is:
If there is a MY_GIT_REPO, in which 90% of the code matches 1 to 1 with ORIGINAL_GITHUB_REPO, but these two repositories do not know anything about each other at all, and the project is private (MY_GIT_REPO) which cannot be posted to the public. So how to be? How to pick up missing 300+ commits from ORIGINAL_GITHUB_REPO and apply them to MY_GIT_REPO? What is the best way to organize such work?
Important note. We are talking about a project with 500+k lines of code, custom changes for 30-40k lines of code, and the remaining 450k lines of code are identical. I can take and compare two repositories using araxis or other utilities, and then take a clean repository with ORIGINAL_GITHUB_REPO and roll all custom changes at once in a separate branch, but this is very, very long, and stop developing the main product.
How to be? How to automate getting patches and applying them a little, given that the two repositories have 90% similar code, and I just got tired of manually adding one commit, tearing it out of ORIGINAL_GITHUB_REPO and adding it to the notepad for MY_GIT_REPO.
With git format patch and git am -3, there are various errors like: not in the index, or something else. But that's okay, because the brunches don't know each other at all.