A (user) story is a helpful standard format for backlog items. The rationale behind it is "if no one cares about it, don't waste time on it". It also allows the PO to assess the urgency of the item because it defines whom you will be doing it for and how bad it is.
In your case the bug can easily be formatted as a story.
As a user
I want to be able to log ...
Distinct specifications of changes and additions to the product, are
called Product Backlog Items (PBIs), that together form the Product
Each PBI describes something that the Developers can develop and
deliver to add value to relevant stakeholders when Done (see
Definition of Done).
The most common stakeholder is the market, or its representative —
The statements that you claim should be true in Scrum aren't necessarily true in Scrum, according to the Scrum Guide.
It is not true, according to Scrum, that you should be estimating user stories in story points. The Scrum Guide mentions neither user stories nor story points. In Scrum, you have a Product Backlog that contains Product Backlog Items, and one ...
The official Scrum answer is "Estimate complexity not time and use Story Points"
However, on a practical note I would say estimation is not something you want to get hung up on. There are a couple of main objectives scrum is trying to achieve which impact estimation.
You can measure progress towards the story in terms of completed tasks.
This means that ...
In sprint planning, flesh out the tasks involved for each story, and estimate these in hours.
I've never split stories into tasks or estimated something in hours. You can do Scrum without any of that if your stories are well defined and small enough.
Instead of trying to do the impossible (estimate in hours without knowing who will do it) just improve your ...