converting latin to utf8mb4 causes questionmarks
Ah, I was afraid of that.  That hex string is the "double encoding" of  أغنية سم الله Does that look about right?

This is the expression to 'fix' it:  CONVERT(BINARY(CONVERT(CONVERT(UNHEX('C398C2A3C398C2BAC399E280A0C399C5A0C398C2A920C398C2B3C399E280A620C398C2A7C399E2809EC399E2809EC399E280A1') USING utf8mb4) USING latin1)) USING utf8mb4)

This discusses how it probably came about.  You need to fix your code and fix the data:  https://stackoverflow.com/questions/38363566/trouble-with-utf8-characters-what-i-see-is-not-what-i-stored  (Look for "double encod")

(utf8 and utf8mb4 work equally well for Arabic.)

That short conversion you found needs to (sort of) be repeated to fix "double" encoding.

Further research

It is OK to be a mixture of Arabic and other languages in a utf8 or utf8mb4 column. It is not ok to have double-encoding, especially if some cells are correctly encoded. Somewhere the Arabic text was encoded an extra time, but the copyright symbol was not. Did they come from different sources? Maybe the problem came before this database we are looking at?

That is, dig into the client(s) you are using and dump the hex of text that is about to be INSERTed. Arabic should be two hex bytes: Dxyy; copyright (and many other popular symbols) should be Cxyy.

Fixing

If you find that some rows have double-encoded Arabic (or whatever) an d some rows have correctly encoded copyright, and if you can distinguish which rows are which, then applying the single-fix vs the double-fix should be 'easy'.

Ditto for columns.  Perhaps the copyright is never in the same column as the Arabic text?

Even messier is when a single cell has both.  That would strongly imply the client is "at fault".