For what it's worth, Puppet probably would not exhibit this problem if it were ensuring 'absent' and package mysql was indeed initially absent. Puppet knows that it doesn't need to act in that case. Purging is an issue, however, because with some other packaging systems it is possible for a package to be absent but not purged. The general Package provider infrastructure therefore attempts to purge packages even if they are not installed, and the yum provider does not override that behavior (though it could and should). Feel free to vote up the relevant bug report:
https://tickets.puppetlabs.com/browse/PUP-1198.
Anyway, a custom fact may indeed yield the best workaround. If it is possible for mysql and percona-client to be installed at the same time, however, then something a bit more involved may be required, because in that case ensuring mysql purged likely removes percona-client as well. Worse, because percona-client was installed at the beginning of the Puppet run, Puppet will not even realize that it needs to be reinstalled. (Score another raspberry for 'purged'.)
Ideally, then, it would be best if the percona-client package precluded concurrent installation with mysql. It may be that a suitable Conflicts: header would serve that purpose, though I'm not sure whether a package is installable or updatable if it conflicts with a feature that it provides itself. An Obsoletes: header might be better suited to the job, but I'm unsure offhand whether it would reliably prevent concurrent installation of the obsoleted RPM.
There might be other, worse alternatives if none of that works out.
John