Const-qualification of parameters in function declaration
The first parameter is of type const char *, or pointer to constant character. This means that you can pass into the function a pointer to a string which you can't modify, for example:
const char* msg = "Hello, world!";
flash(msg, SOME_MESSAGE_TYPE);
You can't change the characters in msg; it's a pointer to const char. Passing it to a function with parameter type char* would indicate the function might change them, which would be illegal. This const in the parameter type is relevant to the caller, so is kept.
On the other hand, enum msg_type is just an enum, and will be copied into the function. When calling the function, I don't care what happens in the body of the function with type; it won't affect anything outside the function. Saying that this is const doesn't make a difference, hence the warning.
If you change the first parameter to const char *const message, then it'll warn about that too. That would indicate that you can't change what the pointer message points to, which again the caller doesn't care about because whatever pointer it passes in won't change.
This isn't really bad; it's telling you that you might be confused, but in this case it doesn't hurt anything. You should still get rid of the warning, though, because warnings indicate potential problems and clogging them with non-problematic noise just makes it less likely you'll read the important ones.
Change the header file, but not wherever flash is implemented, to not have const on the second parameter. Where it's implemented, keep the const so you don't actually change type inside the function body, but it's not needed in the declaration.
I const-qualified both parameter, why does only the latter trigger a warning?
As your warning says, it does not affect a prototype. It only affects the implementation.
Is it really bad?
It is noise in the meaning that it does not affect anything, but other than that, no.
Can I get rid of this warning?
You can safely remove the const qualifier since it is not needed.
However, it seems a bit messy to suppress warnings in general with clang-tidy. This link might help:
clang-tidy: How to suppress warnings?
But these warnings can actually be a blessing. It's not very uncommon to accidentally write int foo(const char *) instead of int foo(char * const). The latter would not trigger this warning, so if you get this warning it's a sign that you have mixed something up.