Idiot-proofing involves a lot more than simple input validation. I wouldn't even include such a thing in its definition.
Input validation is a process where you sanitize and validate user data to both eliminate illegal/nonsensical values. This should always be done with any information coming from outside of your program so as to eliminate the obvious as well as protecting yourself from attacks (e.g. sql injection attacks).
I would consider idiot-proofing to be a set of logic to keep the user from accidentally causing great damage to him/herself through otherwise legal means.
For instance, making
rm reject the command
rm -rf / and close variants has nothing to do with validation or correctness. It's a perfectly valid command. Unfortunately, it's a command which could and can wipe out all of your data from all of your disks in Unix/Linux. Idiot proofing this would reject this command and would suggest
rm -rf --i-really-mean-this /, or if in interactive mode, have the user type in an affirmative response after a warning.
Anything which is destructive to the system should be idiot-proofed. Anything which could cause potential embarrassment might also be a candidate (e.g. "are you sure you want to send this email without an attachment even though you mentioned one in your text?", and "are you sure you want to send this email to the entire company?")
Idiot-proofing is a collaboration between QA (trying to be the best idiot) and Development (trying to anticipate all of these scenarios and designing around them).
As for a more friendly synonym, may I suggest "destructive code-path analysis" or "enable user feedback for critical operations". Whatever you may call it, you should really start it as early in the design process as possible.