I wanted to suggest something like this. Code-freeze wise, you can have a "minor" and "major" problems, major problems block the feature, minor ones let it go (but you now have a tech debt, and make sure that THIS process to fixing up found issues is higher-prio then new features). Of course, you decide what is minor and what major. E.g. maybe a typo in the UI is acceptable, maybe not.
As for throwing features over the wall - I would actually suggest just changing the perspective - make QA involved earlier. The feature is not ready and not frozen unless it's been looked at by QA. Then when a thing is frozen, it's really ready. (Of course you'll still have regressions etc but that's another topic.)
I've ran into Drone CI about a year ago and I like it. I wanted to self-host something simple next to my gitea instance, and after a few hours I had it mostly set up. And in the course of a week I had it all figured out, I don't bother with it any more.
It's basically hands-free operation the way I have it set up, works with my gitea as said so I'm happy.