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.)