vtgate to vttablet: expired MySQL backend credentials and sandbox-mode error propagation across the connection pool

In a Vitess cluster, vtgate terminates the client MySQL protocol while vttablet brokers queries to a backing MySQL instance using its own configured application and administrative accounts. When a backend MySQL account is subject to password expiration or is scoped to a least-privilege role, the failure mode at the vtgate-to-vttablet boundary is not obvious: MySQL places an expired account in sandbox mode after the handshake, commonly returning error 1820, but vttablet maintains a pool of already-authenticated connections that may mask the condition until a fresh connection is opened.

The practical uncertainty is whether Vitess detects this state and re-authenticates or refreshes the credential automatically, or whether the sandbox-mode error is propagated back through vtgate to the client. That behavior may also vary by Vitess release and by the MySQL authentication plugin in use, such as mysql_native_password versus caching_sha2_password, where sandbox semantics and error codes differ.

For operators enforcing least-privilege separation across keyspaces, the interaction between per-keyspace app users and pooled backend connections raises an unresolved design question.

Does an expired or least-privilege MySQL credential behind vttablet surface as a sandbox-mode error to vtgate clients, or does Vitess transparently recover? How does connection pooling affect when the failure appears? Are there version-specific differences in how this is handled across supported Vitess releases?