[SOLVED]
The most inelegant solution, utilizing almost zero SQL understanding, was able to help me fix my problems. I created the new journal instance, fresh OJS 3.3.0-3, with an untouched database. From the old database, which had failed the upgrade, I compared the values, tables, and necessary data across both setups, updated the column values, deleted and added information based on the import of the tables and the errors spit out by phpMyAdmin, and was able to bring (almost all of) the site back up and functioning.
I never want to go through this again so I will echo statements and everything by @asmecher and others - keep backups on backups on hand. I created a new backup policy for the primary volumes stored on our servers for a rotation of stored backups just in case something like this happens again and I’m unable to work on it for as long as I was able this time.
I’m now going to apply user permissions to my primary admin account so that I can access all of the features of the journals that were restored, as well as update all the customization information that I had worked on.
Thank you.