The terminology is less than ideal because these two terms have completely different origins and constraints. In particular, Rust didn't get to choose "undefined behavior".
unsafe is a Rust keyword. As a keyword, which some code needs to use several thousand times, it can't be super long. And in practice, "memory safety" is the only kind of safety that Rust-the-language understands, so "unsafe" always means that kind of safety. Thread safety is a special case of memory safety, and all the other kinds of "safety" I'm aware of are impossible to define at the level of a programming language.
"undefined behavior" comes from C/C++ standardese. Consider this (in?)famous, um... definition?
3 Terms and definitions [intro.defs]
behavior for which this document imposes no requirements
Not exactly unambiguous to the non-expert.
AFAIK this term is only a popular, semi-standard cross-language term because a) C/C++ have been the only important languages with optimizing compilers for a long time, and b) you cannot use C/C++ in practice without a lot of language-lawyering. Unfortunately, misconceptions about precisely what UB means in theory or in practice and what a healthy attitude around UB looks like are about as widespread as the term itself (I recommend https://www.youtube.com/watch?v=yG1OZ69H_-o on that subject).
Whenever UCG gets to the point that we begin seriously thinking about enshrining their UB rules in official Rust RFCs/the Reference/an actual spec, we should bikeshed the hell out of this "UB" term. But it's still the best term to use for this concept in the short term, because it's the mostly widely understood term that exists today, and Rust is clearly going to need that concept no matter how the UCG works out.