Language vision regarding safety guarantees

I wouldn't say "safe code can cause UB". It's rather one of:

1. Safe code can be a victim of invalid assumptions or bugs in some unsafe code, and end up being a trigger of UB despite not being at fault (e.g. unsafe code can return &mut to safe code that is non-exclusive or NULL. Safe code using that reference will blow up, but only because it was given an already-broken state).

2. Safe code may sabotage an unsafe block that relied on the safe code to behave in a certain sensible way.

The second one is trickier to define. For example, if you have an unsafe block that stores a bunch of pointers in a Vec, it will likely depend on the Vec acting sensibly, preserving the order and not shuffling the elements for no reason. If Vec misbehaves, code using it will misbehave too, and that will have worse consequences in unsafe.

In the second case whose fault it is may be very context dependent. In case of trait implementations, unsafe code typically has an obligation n to trust the implementation and has to be coded defensively (e.g. unsafe code must not trust Ord. Some Ord impl might return random ordering, which would be dumb thing to do, and may result in collections heaving messed up content, but it can't be messed up any more seriously than a fully-safe code could mess it up).

In the end, you have to trust that something in the language works as documented. 2+2 is safe, and has to return 4. It would be unproductive to mark it as unsafe and allow it to return 5. It would also be unproductive to say that unsafe code can't rely on 2+2 because add may be buggy.