First of all, most issues with process issues are more a reflection of the organization and what drives them than the process. I would say you should start talking about, 'Our process' instead of 'Scrum'.
>These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I need to up my game with how to play it - but I wish I could use something else, perhaps kanban.
Spoiler, your Scrum books aren't going to help you figure things out, unless your org actually wants to change. You have your own unique process, but that you have a unique process isn't an issue. The issue is that your management seems to not respect the input of engineering. No process will work the way you want as long as that is true.
Some thoughts,
* Most critical, your team is way to big. Should be half as big
* Scrum master should be a team member and rotated along the team. The process should be a result of constant tuning via the Retrospective. The scrum master here, should lose his job.
* Engnineering owns the implementation of the stories, product owners should not be a part of the conversation on how to do something, they only can say 'what'.
* If you can't decide your own points, then again, you have your own process. If you can, and you need to refactor, you need to add points for that.
If you can't do anything to change, then again reading scrum books isn't going to help. You can say, 'this isn't the way your supposed to do this' as much as you want. processes always reflect the organization. Unless the engineering team is an equal to the product team, it won't matter what process you have.