Note that the client would only need to do this on a failed attempt.

So if i typed "Password" on mobile. The client would first send the request as "Password". If that succeeds, then no worries. If it fails, then the client could send a second request by reversing the case of the first letter. In this case, it would send a second request for "password".

At most, it is 2 login requests per password. Many other commenters here are incorrectly stating that 3 requests would be necessary, but this is untrue. A letter can only have 2 possible cases (uppercase or lowercase). So the client sends the originally typed one, and if that fails, then it flips the case of that first letter. That is the only alternative. There is not a third option.

A well-built login form would restrict users after 3-5 login attempts anyway and require a password-reset process. So that is 6-10 client requests to the backend (n * 2). That shouldn't be hitting any sort of rate limit.

Why would you need the client to send the request over and over when you control the backend?

Not to send the password in plain, maybe?

Are you aware of transport encryption?

It would only half the rate limit, but any real brute force attempt requires way way more than what a normal human would try. Something like 5 attempts would double to 10 in the backend, still nowhere enough to bruteforce, but enough for human trial and error.