I'm not sure I understood completely your question. But if you are referring to discovering a lot of bugs very quick by the two testers, then the fix for this is for the developer to do unit testing and integration testing or basic feature testing/requests testing (depending on your architecture).
> Should engineers/devs be expected to do very basic and rudimentary testing of a feature outside of a unit test before saying it's ready for QA?
First about Unit Testing: this type of testing will usually assure a developer that the classes or modules or functions are working as the developer expected. This is very different than verifying that the feature works as the client or end-user will expect.
Here is an example: With Unit Testing you will probably verify that a Class that is exporting PDFs is exporting them and no errors are present during the export. It might also test that if a footer is defined it will include it at the bottom of the page.
But when looking at System/Acceptance Testing (or feature testing) one should look that the information that brings some value to an end-user is present or maybe that it looks accordingly with the color scheme of the branding.
So basically yes, they should do more than Unit Testing. Or if you are into an agile environment you can do some kind of "pair testing" (not sure if this concept exists) where a developer and a tester are working together to write tests.
Ref to the second part of the question I think you are looking to some kind of Definition of Ready for QA.
And here is one simple metric:
1) I finished writing code
2) I finished writing some unit testing (you can choose a level of code coverage for unit testing depending on how much time you want to invest in it).
3) I _at least once_ opened the application and followed the story to see if from the perspective of the end-user I implemented it correctly (if it has acceptance criteria then I will follow that)
Of course step 3 can also be automated by writing some kind of automated acceptance testing (or at least a basic functional scenario).