I would like to tag certain commits as "tested" or "rejected" depending on the success of certain regression tests (similar to clearcase labels)
Regression testing itself is not automated (these are long running tests unfortunately).
However, I'd like to have a warning when attempting to checkout old commits that have been rejected or not tested at all.
It would be nice if anyone pulling from the repository will get the tags as well (and similar warnings when checking out rejected versions).
You can get tags from the remote repository, git fetch <remote> --tags. That does rely on someone doing it on their own.
Git's tags will travel across repositories if you specify that they should (git push --tags). There won't be an automated warning, but perhaps that can be built.
But you're asking about best practices:
I don't think cherry-picking by non-team members is a best practice. In general, people will announce which branches of their repositories contain "known good" code. They will also revert commits that are "known bad". If you never look further than a single commit, you would miss the revert.
I'd say a further best practice is to use multiple communication channels:
If you want to do the "known good" option you can rename branches. So you have a stable and an unstable (or just current master's HEAD) and you can move the stable branch whenever there's a new known good "passed" revision. Something like this:
git branch -m stable master