Should a Scrum Master prevent a Product Owner from directing technical implementation during a sprint?

There's no justification inherent in the role for the Product Owner to be involved in technical decision-making or implementation. This lies exclusively with the Developers.

I have seen cases where the Product Owner (and sometimes the Scrum Master) were developers in the past and have familiarity with the tools, technology, and sometimes even the specific product. In these cases, it may make sense for the team to ask for help working through the problems or potential solutions to gain another perspective. However, it's always initiated by the Developers, not forced upon them.

The PO should not decide what the eventual solution will be. But if the mere act of making suggestions is found offensive by the developers, I'd look for why this is the case more closely. Is the PO formulating their suggestions in an extremely assertive manner, without really having all necessary information? Do they use the common communication style where they talk like it is totally clear what is happening, painting the dev in a bad light? Or did they just sit down on a Sunday, google the issue, and find some suggestions on StackOverflow?

If the suggestions are formulated in an objective offensive way (i.e. painting the developers as incompetent), then you can and should for sure give appropriate feedback to the PO. As the Scrum Master, your job is to ensure the whole setup works well, conforms to processes, and so on and forth, so if you see that this kind of behaviour leads to devs becoming more defensive and guarded, it is for sure in your purview to involve yourself.

If on the other hand the suggestions are perfectly fine; simply objective pointers or guesses as to what could be going wrong; especially maybe with added information known to the PO that was for some reason not contained in their original requirement, then maybe checke with the developer/dev team instead. Maybe it's time for them to learn how to receive (objective, constructive, non-personal) feedback in a more positive manner. It can be very wise to be able to take this kind of input and do with it what makes sense; i.e. don't take it as gospel, but include it as possibly issues/solutions to whatever the eventual technical problem is.

In any case, if the discussions around this take up more time than seems appropriate, use the usual scrum mechanisms - i.e., in this kind a dedicated refinement session - so the PO can give their feedback in a structured, time-boxed manner. After all has been given, the PO should indeed return to their role; they are in charge of prioritizing their backlog, so they are free to put this item at the top for the next sprint.