Can PO add bugs/issues in Product Backlog or only Development team is allowed to add bugs?

Which do you think is most conducive towards inspection and adaptation in a timely manner: the reporting of things, or collaboration between team members?

As the Scrum Guide says "The Product Owner is the sole person responsible for managing the Product Backlog.". I would suggest the team talk about this in a Retro and agree on an approach. Assuming the PO knows the product better than anyone, which they should, the PO should be able to determine if a reported bug is actually a bug or working as designed. I've worked in a few organizations where the PO is the filter for any production bugs and validates it is a bug before moving it into the Product Backlog. This, of course, requires trust between the PO and the Development team. if you're story pointing bugs, they would have to be discussed during a refinement session, which could be the final confirmation. 

I'm trying to make them understand that PO can report bugs in PB. During sprint planning, he/she will discuss those bugs and at that time you can discuss/validate if this item is supposed to be bug or enhancement or user story.

I would like to point out one of the Agile Manifesto - 

Individuals and interactions over processes and tools

What do you think is underlying problem process/reporting or interactions/collaboration ? 

depends on where the bug is coming from.

If it is a bug from a story in the current sprint, it should not go to the PB. In that case the SBI is not done.

In case it is a bug or misfunction from a previous sprint, it should not go in the current sprint, but on the PB. If the PO would like it to perform differently, it is in his responsibility to add it to the PB. And only things that are on PB and/or SB shall be worked on by the Dev Team.

And the PBI will be discussed in PBR or latest in Planning.

Opening paragraph from the Scrum Guide section on the Product Backlog

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

Also from the Scrum Guide section on the Product Owner

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog.

I fail to see why a Product Owner can't enter defects into the Product Backlog if it something that "is know to be needed in the product:. At the point the Product Owner created the ticket they felt it was needed.  If the behavior of the product is not what the Product Owner expects then a change is needed.  The "entire organization must respect" the Product Owner's decisions.  Whether it is a bug or a missed opportunity makes absolutely no difference.  It is a change that the Product Owner feels is needed. 

This is one of the reasons that I coach the use of only 1 type of item in Product Backlogs.  If you create the items as different types, there is too much temptation to address them differently.  But if all Product Backlog Items are created exactly the same way everything is more likely to be treated equally.  I know that most electronic systems used for managing tickets allow different types.  But there is no reason that you have to use the different types.  Human nature is to view differently classified things in unique ways.  So make it easy and just have one type of item that conveys the information in the same manner.  If you use User Stories, write defects as an User Story. 

Thanks guys for all your responses.

After going through them, I realize that I need to teach/coach my team better in being agile.

Daniel Wilhite I really like your idea of 1 type of item in PB, definitely will give it and introduce it in our upcoming retrospective.

Thanks.