If your language promises some kind of new feature (e.g. "safety") but offers a back door you could drive a truck through (e.g. 'unsafe'), then ensuring that back door is used appropriately and in good taste comes down to culture policing, which, as we've learned in other areas, is something the internet does not handle well.
As the Rust community grows, how can it ensure that people use 'unsafe' tastefully? Well, in general, it can't. But maybe Cargo could exercise some editorial control, and delist (or flag) packages that don't follow the "community standards". I'm not saying this would be a good idea, it's a tradeoff. But you can't force open source volunteers to write code in a way you like.
I would prefer to see a positive badge for "this project doesn't directly use unsafe" or similar, which maintainers can choose to put in their README in the same way that they currently put build-status, test-status and other badges. The actual badge state is produced by tooling (a CI system) so it stays up to date and you can follow a link to a (tooling generated) report with more info, so it's relatively easy to verify.
Maintainers that don't care don't have to use the badge (even if their project does in fact avoid unsafe), but the choice to include the badge acts as an implicit signal of intent. When I see a crate with green CI status badges (or in this case a green safety badge) that's a signal I can use to help judge whether I want to depend on the crate.
No one needs to be flagged or called out if they're not interested in that aspect of maintainership.
I think the hard part is that actual quality is a spectrum and no-unsafe-at-all isn't necessarily the best goal for many crates. So ideally the badge would show some more granular safety score. But scoring effectively is difficult, and the so is correctly interpreting a heuristic score.