First, the previous answers are good and bring up different view points to consider.
I agree that management shouldn't be finding ways to blame QA for missing bugs or finding bugs in unexpected, unplanned ways. That's a huge benefit to the team and a good skill to have when doing testing.
My take on this is why is there only "happy path" test cases being considered when doing test planning? To me, this is a bare minimum to what QA should do. Why not plan for negative test cases during planning or "sad panda" paths/scenarios? This can certainly be done based on the given requirements of a feature/story.
If the requirements in the ticket only mention positive aspects of what's to be expected, you can ask about different negative aspects or different states a user can expect.
As an example, if you have a requirement that states "a user should be able to create a password with a specific character set." Then you can ask about error conditions or error messages a user should get if they don't follow that password guideline. You shouldn't have to wait until testing is in progress to say "I found a bug. When I input non valid characters, I don't see an error message when I expect one." You can and should know this ahead of time!
While you can't expect to know of all test cases ahead of time, you should be able to use the right testing techniques (like boundary value analysis, equivalence classes, state management, etc), prior application knowledge, and prior usage of similar apps to uncover more tests cases.
The well known tester, Michael Bolton, has a heuristic called FEW HICCUPPS that can be used to guide test case creation. The acronym stands for:
Familiarity - how familiar are you with your product or similar products?
Explainability - can you explain or understand the behavior of the product?
World - is the project/feature consistent with your prior observations and general view (familiarity) of similar software products?
History - are the requirements consistent with prior versions of the software?
Image - are the requirements consistent with the branding, marketing, reputation of the company?
Comparable Products - similar to familiarity and knowledge of similar software products.
Claims - are the requirements consistent with prior expectations?
Users Desires - are the requirements consistent with inline with what the users or stakeholders want?
Product - are the requirements consistent with or integrate well with other features of the product?
Purpose - similar to user desires.
Statutes and Standards - are the requirements consistent with inline with any laws, standards, regulations?
The details and definitions of each of these can be long, so I don't want to go into too much detail of them. I highly encourage reading the link.