Actually, it seems I may have been wrong in initial assumption that the issue with the client was that it was being identified to mysql as coming from localhost when connecting via tcp.
This is what syslog indicated as a reason for the failure but its not the whole picture.
As John mentioned I am trying to have dovecot connect over TCP to mysql (not using the socket), and the issue looked like the cause was the identified by portion of mysql being read by either mysql incorrectly or the domain portion being overwritten on dovecot's end (I don't know about the internals enough to say for sure where).
Just as due dilligence, I added credentials for a mysql user identified by localhost and removed the jail since the dovecot error was stating that it failed for connection by user@'localhost' (where there weren't credentials).
After adding the credentials, I performed all the usual mysql tests before moving testing up to dovecot and still get an auth failure. The log seems to be a bit of a red herring or at the minimum doesn't show the whole picture.
Replacing the connection string host with the socket (host=localhost) and everything works, and using an external IP that's not 127.0.0.1 works as expected as well. (confirmed by standing up two isolated mysql and dovecot containers and setting auth up over the bridge).
If the issue was caused by user@'localhost' creating the credentials should have resolved it, and it didn't. So something weird is going on.
I've got the environment built up in a dockerfile I can provide if anyone wants to dig into what's causing it.
In the meantime due to time constraints, I'll just be working with the socket file from now for hosts running most of the mail stack all in one.