Nitpick: not all bugs have to be reproducible to be taken seriously. Defensive programming, and adding extra logging could be a mitigation to avoid future problems, or to help fixing them in the future.
Imagine you're writing trading software, you have an algo go haywire and it machine guns the whole order book, and then you refuse to put a "max order size" outside of the algo to stop it from happening again because you can't figure out why it happened in the first place.
Try telling a regulator or your boss that was your reasoning.
Even if the bug can't be reproduced, on the basis of multiple user reports the first step absolutely should be to add some assertions and logging around email deletion.
The point is not to give it a "100% safe" label, the point is to start narrowing down possible root causes. If the problem recurs again, you'll have assertions ruling out certain possible culprit code paths as well as logs displaying the values of relevant variables.
1. Validate input, expect all external input (both human and machine generated) to be completely bogus.
2. Fail fast and early. If something seems off, crash straight away, and do not expect things to magically repair itself at a later stage.
3. Use pre- and post-conditions where appropriate.
I'm not sure about the exact definitions of defensive programming, but static type checking, and possibly unit testing, might also be part of it.
The answer is that you keep working at it iteratively using a combination of logging, reporting, and defensive programming to systematically narrow down the possible causes. Sometimes you never arrive at a true root cause, but you get close enough that you can mitigate the problem and finally close the ticket out. At the end of the day, the customer/user doesn't care as long as it works.
However, what will really piss them off is telling them your hands are tied until they can reliably reproduce the issue for you. It's important they understand that you are working on it, and typically they will go out of their way to help solve the problem when they feel taken care of.
This happens more often, for example when many services work together in an asynchronous way, and in some very rare situation, unwanted behavior occurs. To fix that, it is often easier to reason through the entire process, and to identify weak spots. It might even be a good idea to switch to a different paradigm to avoid certain bugs altogether.
For this particular bug, I would start by reading a lot, and ensurong that the bug is indeed not easily reproducible (by trying to make it reproducible of course). If that fails, I would continue to think about root causes for the bug, and possible workarounds that would work in theory. Then I would try to estimate the amount of work required, and the risk of breaking other things, and report that to those who like to decide on further actions.
And of course, as I know very little about the inner workings of ThunderBird, I would simply ask ChatGPT o3 or similar for advice. It comes up with a plan that seems reasonable.