Right, it would likely use clippy but it would essentially be a --production target or profile, intended for builds where the binary will be run in production.
And by 'and friends' I mean calls that panic for the same reason as unwrap, such as expect or ok.
The goal is to stop code from reaching production inadvertently, not to prevent all sources of panics.
But if we accept the premise that "it's acceptable in some cases to have unwrap() in code that targets 'production'" then it wouldn't make sense to have a production profile that bars its use. The word "production" is in the global namespace and I think you want something more specific to your use case.
Rather, one could define a rust coding guide for themselves that deems unwrap() inappropriate for production use. (and in that case use the lint Steve suggests).
Seems like you'd want a lint rule where if unwrap is used, it must have a comment preceding it (of some formal syntax) describing why it's necessary or appropriate. Thus the build can have all uses of unwrap known as explicitly allowed, allowing all the possible sites of panics to be enumerated and known, a useful property to have
The goal is to stop code from reaching production inadvertently, not to prevent all sources of panics.