TL;DR
[O]ur Product Owner introduced a bug to the Developers and said, "Let's take this bug and see if we can fix it quickly. Otherwise, let's put it back on the backlog." I have asked what the Product Owner mean tby saying "quickly," and she said "within 10-15 minutes."
This isn't really either a story spike or new work, and the ask from the Product Owner is extremely reasonable. The right way to think about this type of work is as triage, defined by Merriam-Webster as:
the assigning of priority order to projects on the basis of where funds and other resources can be best used, are most needed, or are most likely to achieve success[.]
Analysis and Recommendations
First of all, the request to include some triage within your planning event (I hesitate to call it Sprint Planning) or within your iteration is extremely reasonable. If introduced during planning, then add a very small story, chore, or other similar item to your backlog if you're unable to perform the triage during the planning exercise itself. The triage then becomes planned work, albeit very small work.
The practice of have a number of small tasks or chores that collectively add up to 0.5 or 1 point (assuming you are using story points) is not uncommon. Every team has little things that need to get done during an iteration, so you should either reserve capacity for small miscellany like bug triage and other chores, or you should routinely adjust your capacity and your iteration plans to account for them. All effective agile implementations require some reasonable level of slack; without sufficient slack, the plan becomes extremely brittle!
Secondly, if you don't have 15 minutes of slack in your iteration to determine whether a presumably non-critical bug can be easily fixed or should be deferred to a future iteration when sufficient time can be scheduled to fix it properly is completely reasonable. A bug that's easy to find and caused by a simple typo doesn't even deserve the overhead of being a backlog item, but a bug that may take hours to track down before you can even determine a root cause is something that should be scheduled as it will consume significant team capacity.
If it's not tied to your current Sprint or Product Goal—since you aren't doing Scrum then it likely isn't—or being treated as a high-priority issue, then asking the team to spend 15 minutes to perform a very limited amount of triage solely to determine whether or not the work is trivial—note that you aren't even being asked to estimate the work beyond "really trivial" or "more than 15 minutes worth of work to assess, estimate, or prioritize"—means that you have a very agile Product Owner and should be taking notes!
Perform the triage within your iteration as requested, with a total time box of 15 minutes. I'd recommend that you spend no more than 5-10 minutes figuring out whether this is something that will take more than another 5-10 minutes to fix. If it can be fixed within your time box, do it. Never touch the same piece of work more than once if you can help it! Otherwise, let the Product Owner know what you found, and whether you can help prioritize the bug or estimate the level of effort needed to fix it based on your cursory inspection.
If a story spike or further analysis needs to be planned, then the bug goes back to the Product Backlog. The next time it's in scope for iteration planning, you can work as a team with the Product Owner to decide what stories or Product Backlog items are needed to address it, and how much time or effort you think it will take.
The Product Owner is correct in taking this approach. The Developers should support it, and the only legitimate objection would be if the team as a whole has failed to allocate sufficient slack to its iterative process. If that's the case, then that's a whole-team process problem that needs to be addressed. Such a process problem is not directly related to a minor triage request, so the resistance to such a request doesn't seem reasonable for any process intended to inspect-and-adapt or promote validated learning within an iterative process.
