He's not looking at it the wrong way.
You're essentially saying "But a technology that does this would be very valuable!"
Yeah, no shit. So would a technology that turns lead into gold. Or that can tell whether some unwatermarked text is LLM generated or not.
Like both of those cases, it's just not possible. C needs to be translated to Rust by someone who knows the intent of the programmer, as the GP pointed out. Most of the time that's not possible to automate. There are far too many edge cases.
In C a string is an array of chars. And chars are often used as a byte type because before the second ANSI standard, char *was* the byte type. So every time you see char a[256] you MAY be looking at something intended to hold a string, but you also MAY be looking at something intended to hold series of bytes. You may think that because someone wrote something that maybe even included a string initializer that you're dealing with a string, but the developer may well be treating it as something else.
Your very example is why this kind of thing isn't automatable without a huge level of hand holding.
The best anyone can do to make "safe C" is to emulate capabilities and make it do that. Which is chronically slow. And the reality is that even capabilities aren't a panacea, because C really is just that bad. You'd get rid of some classes of error, but UB means you'd almost certainly introduce a whole set of bugs from programmers unaware how big an issue UB is, and who assume ultimately memory is just a big byte array, and some of those errors may well be security holes.