I believe if you write tests hooking up your tests with the test allocator will effectively prevent all blatant UAF and memory leak events. More subtle ones that happen due to spooky action at a distance and wierd incomposability might be out of reach.
(Not at op, who does write tests:) You are writing tests, right? ;)
Testing is a good way to ensure that your program won't have UAF under most normal circumstances. But when it comes to security it's adversarial - your program will get pushed into parts of the state space that were never seen during testing.
Things like browsers and operating systems are all heavily tested and fuzzed using tools like asan. They still have security issues from UAF.
if you're worried about errors coming in through testing and fuzzing, you could be just as in trouble in a language as rust due to, say an unsafe block not composing well with another unsafe block two dependencies over. The challenge then is to figure out how to debug, I would worry that obsession with "zero-cost abstractions" making your code difficult to reason about and obscure the bug more than a system that has a more barebones relationship with the computational processes. However, only time will tell which is the better strategy.
(Not at op, who does write tests:) You are writing tests, right? ;)