This seems acceptable IMO. The general working conventions already are to separate whitespace and/or tab changes from a commit containing actual content. If you ./validate cleanly, but the server rejects the push for whitespace, adding an extra commit on top to clean up the affected files seems very sensible (it's simple to 'untabify' and eliminate trailing white space in most editors these days, so I imagine this isn't really going to cost you a lot of time.) I also add bonus points for the fact the server will reject it unless you clean up *all* affected files you touched, so things can't slip by. This is how the tab check works now, and it does deal with a 'range' of commits where later commits eliminate tabs introduced in earlier ones.
We'd also have to introduce the concept of git into ./validate for this to work (and add the ability to specify a commit range for stuff like this,) but a basic implementation may not be difficult, looking at the pre-receive script.
Alternatively, these could be pre-commit hooks in the developer repository, but I believe you have to opt into that. Maybe worth putting on the wiki, though.