Bug reporting process

I suspect the answer to this will be wildly different for every team, and it depends on how you want to prioritise bug resolution.

1. You could put less work into your sprints to give devs breathing room (if a sprint item takes longer, or a bug comes up that needs to be fixed urgently, time to triage and investigate bugs, etc). If you get a delayed sprint that just means the next sprint has to have less work in it.
2. It's perfectly ok to deprioritise one-off bugs, extremely rare bugs, or very low-impact bugs. This will be part of your triage process. There's no reason to be spending time working on those if you're short on dev resources.
3. The un-estimable part of a bug is usually identifying its root cause; if that's done and a resolution is clear, then that can just be a normal sprint item, prioritised along with the rest of your issues.
4. Different clients will have different opinions on the priority of their bug. I'd recommend, especially in the early stages, collecting feedback on how it impacts them. If a bug seems low-priority to you but it's bothering a paying customer to the point where they might churn, it might be worth prioritising it.

Ultimately it comes down to how much breathing room you want to build into your sprints for investigating bugs. There needs to be an explicit chunk of developer time available for that; trying to run sprints without taking into account bugs is only going to crash and burn.