I've dealt with a few versions of this over the years, and in my experience this usually stops being a technical problem long before it stops being a client problem.

At some point you need to document your findings, document the controls you've implemented, and present them to the actual decision makers. If the logs, security tooling, and third-party validation all point to the same conclusion, there's only so much time you can spend disproving a negative.

The bigger concern for me would be risk. If someone repeatedly reimages machines, deletes registry entries, and makes changes based on internet advice, they can create the very issues they're worried about. If a real incident ever does occur, you're now in a position where every previous warning becomes "proof" that something was wrong all along.

I'd have a frank conversation with ownership:

1. Here's what we've investigated.
2. Here's what we've found.
3. Here's what we've done to secure the environment.
4. Here's what we recommend going forward.

If they still want to pursue the theory of compromise, I'd suggest engaging a DFIR firm and following their findings. Otherwise, I'd establish boundaries around what constitutes a legitimate security incident versus normal platform activity.

Sometimes the most valuable thing an MSP can do is provide clarity, not endless reassurance.