'allow upload csv' invalidates the db user password using Cloud_sql_proxy metabase v1.49.3

As soon as I enable 'upload files' to a certain database that database connection gets invalidated by the combination of cloud_sql_proxy & the way in which JDBC is making the connection (I'm not sure who's to blame).
Steps:
mySQL 8.0 (gcloud hosted)
Metabase 1.49.3 (docker image in kube on gcloud)

show grants for user 'demo' looks like
"ALL PRIVILEDGES for tables demo"
"ALL PRIVILEDGES for tables demo_wh" (warehouse for etl))
"ALL PRIVILEDGES for tables demo_la" (loading area for etl)

interestingly, only the database which has 'upload csv' turned on crashes. I was able to continue using the other DBs connected without going to fix that one's credentials.

1.49.3 seems to be working fine unless 'upload csv' is turned on.
When that happens, I have to go change the password in 'Admin > Databases > demo'
It is NOT necessary to change the password in mySQL 8.0 for that user. (I thought it was, and tried that first, it also worked, but just by typing it back in to metabase, without changing the pw in mySQL itself was enough to reset the connection properly).

Please let me know if you'd like any additional details.

Here's my error log:
2024-04-18 12:59:55.470 CDT
"(conn=2562313) Access denied for user 'demo'@'cloudsqlproxy~MYPASSWORD' (using password: YES)\nCurrent charset is UTF-8. If password has been set using other charset, consider using option 'passwordCharacterEncoding'",
2024-04-18 12:59:55.470 CDT
:row_count 0,
2024-04-18 12:59:55.470 CDT
:running_time 0,
2024-04-18 12:59:55.470 CDT
:preprocessed
2024-04-18 12:59:55.470 CDT
{:database 3,
2024-04-18 12:59:55.470 CDT
:query
2024-04-18 12:59:55.470 CDT
{:source-table 69,
2024-04-18 12:59:55.470 CDT
:fields
2024-04-18 12:59:55.470 CDT
[[:field 798 nil]
2024-04-18 12:59:55.470 CDT
[:field 797 nil]
2024-04-18 12:59:55.470 CDT
[:field 793 nil]
2024-04-18 12:59:55.470 CDT
[:field 795 nil]
2024-04-18 12:59:55.470 CDT
[:field 796 nil]
2024-04-18 12:59:55.470 CDT
[:field 794 {:temporal-unit :default}]],
2024-04-18 12:59:55.470 CDT
:limit 1048575,
2024-04-18 12:59:55.470 CDT
:metabase.query-processor.middleware.limit/original-limit nil},
2024-04-18 12:59:55.470 CDT
:type :query,
2024-04-18 12:59:55.470 CDT
:middleware {:js-int-to-string? true, :add-default-userland-constraints? true},
2024-04-18 12:59:55.470 CDT
:info {:executed-by 2, :context :ad-hoc}},
2024-04-18 12:59:55.470 CDT
:data {:rows , :cols }}
2024-04-18 12:59:55.470 CDT
{}
2024-04-18 17:59:55,500 DEBUG middleware.log :: e[32mPOST /api/dataset 202 [ASYNC: canceled] 4.6 s (16 DB calls) App DB connections: 1/15 Jetty threads: 2/50 (7 idle, 0 queued) (64 total active threads) Queries in flight: 0 (0 queued); mysql DB 3 connections: 0/0 (0 threads blocked)e[0m
2024-04-18 12:59:55.696 CDT
2024/04/18 17:59:55 New connection for "MYPROJECT:MYDB"
2024-04-18 12:59:55.797 CDT
2024/04/18 17:59:55 Instance MYPROJECT:MYDB closed connection

What exactly is a cloud_sql_proxy? ... If you have google GKE and Cloud SQL the two instance can see each other and you can connect directly no?

Cloud SQL Proxy is a utilty usable for connecting to DBs in a project, while 'proxying' them to reference localhost. It makes use of IAM properly, (so, is a tad better inherently than storing the credentials on the box, or in the metabase UI).

For our purposes, this allows us to tell the metabase container to access our database via 127.0.0.1 instead of exposing a public IP to the database. (The instances are in different projects also, for unrelated reasons).

I was unable to tell via the logging why the credentials are getting blocked, but the symptom is that if you enable 'csv uploads' on a db, it attempts to connect to that db with an incorrectly encoded password.

I was able to use this feature using the same Docker image, on a box where the database is connected via IP. So, it appears to be something special about the way the Metabase MySQL connector is working with Cloud SQL Proxy when attempting login / connection initiation.