For the immediate future, you need to spend more time working with the Product Owner and less time focusing on the development team. You and the Product Owner both need to spend a couple of sprints refining your roles and learning to work together, and you both need to gain a better understanding of your respective roles in the Scrum process.
Fix Your Adversarial Relationship
The Product Owner is part of the Scrum Team, not an outsider. You want an engaged Product Owner; many Scrum Teams would be lucky to have the problem of an overly-engaged one.
So, before you do anything else, make sure you understand that the Product Owner is an active member of the team, and that she is ultimately responsible for setting priorities for the project. The development team sets the pace, while the Product Owner defines what should be done at that pace. If she chooses to allocate sprint capacity to additional planning, training, or story spikes, that's her call. Your job is to make sure her priorities are clearly visible within the project, and communicated clearly within the team and throughout the organization.
Involve Yourself More
As a Scrum Master, you have a number of responsibilities. One of them is educating Product Owners on the role they play in the process. Another is actively working with the Product Owner to perform Backlog Grooming to ensure the Product Backlog is in good shape for Sprint Planning.
Here are some ways you can make sure you're holding up your end of the process.
Education is Needed
If your Product Owner is new to the Scrum process, or not engaging properly within the framework, this is an educational task that you are responsible for. Take the time to talk with her about backlogs, sprints, estimation, and the various meetings and artifacts that go along with Scrum.
In particular, you want to take some time to explain about time-boxing, and about the appropriate meetings for discussing new user stories, decomposing epics, estimating stories, and the other things that she wants to do. The things she wants seem reasonable to me; it may just be the fact that she wants to do them outside the framework that's causing you difficulties.
She may also need some advice or guidance on how to develop user stories, or on how to prioritize them in the Product Backlog. You should be providing that advice, and spending some additional time during Backlog Grooming in particular to make sure that her questions are being addressed properly within the framework. The Product Owner and the Scrum Master must be active collaborators, so step up to the plate in this area in particular.
Adjust Your Velocity Expectations
Keep in mind that on-boarding new team members will have an impact on your velocity. That's fine; it's all part of the process. Adjust your velocity expectations accordingly, and make sure you communicate about the adjustments clearly and non-antagonistically with the Product Owner. It is probably more important for the Product Owner to get up to speed with the team and with Scrum than it is to maintain an artificial velocity level for its own sake.
Part of your role is to communicate effectively about velocity, including what it measures, what may impact it, and how changes to the team's velocity may impact project schedules. Your role is not to control the velocity, but rather to report on it and help the organization to use the metric effectively in its planning.
A new team member, especially a new Product Owner or Scrum Master, will have a big impact on project velocity. As the Scrum Master, it's your job to make this impact transparent and visible, and to help set everyone's expectations accordingly.
Leverage Backlog Grooming and Sprint Planning
If your Product Owner isn't getting enough information, or not understanding how to get the right information within the Scrum framework, then it seems likely that you are dropping the ball during Backlog Grooming, and communicating poorly about when decomposition and estimation should be done.
Backlog Grooming is the defined meeting for the Scrum Master and the Product Owner (and sometimes the entire team) to discuss the Product Backlog. Identifying which stories are epics, which stories will probably need decomposition or refinement before being accepted into a sprint, or discussing the priority of backlog items are all constructive topics for Backlog Grooming.
Decomposition happens either here or in Sprint Planning. It's better to do it in Backlog Grooming when possible, but decomposition often happens in Sprint Planning too, simply by virtue of the fact that Sprint Planning is more about near-term, fine-grained planning.
It's your job to facilitate these framework-defined meetings. Especially with a new Product Owner on the team, you may need to shift more of your attention away from the development side and onto the backlog management side in order to get the entire team back on track.
Make the time. It's your job.