Tanner is spot on with his responses...trust!
I would add on to the story point conversation to make sure you stress comparing previously sized stories to the new ones. "You are sizing this a 1, but the last time you sized a 1 it was this story. Is this story the same complexity?"
There is a lot of "debate" among coaches if the PO should size or not. My 2 cents would be that if the PO has practical hands on experience (within the past year) with the team product he/she can help the team size (notice I said help). Estimations in an agile team are supposed to be purely for the team to build a consistent flow in order to make a commitment of work they can accomplish. If anything is being estimated that is smaller than a sprint (story, task) that isn't a team member, it's micromanagement and removes trust.
The team needs to clearly define the definition of a bug and own it if it happens to meet that criteria. Ambiguity around is it a missed requirement, working as designed, or code fault is never a good start. One way to approach this is to have the team come up with their working definition of bugs.
1- Any issuesfound within the sprint that are from the sprint backlog are fixed immediately and are not classified as a "bug"
2- Bugs should have an expected and actual outcome with steps to reproduce
3- etc. etc.
At the end of the day, bugs are bugs. Sometimes the team created them, and sometimes they inhereted them. Bugs should be seen as more of a way to show opportunity and technical excellence changes rather than a method to punish a team. I would also challenge the team to not only fix bugs, but make it part of the acceptance criteria to show how it can be prevented in the future with an automated test or manual regression step.