Is it safe to store APK signing passwords in private git repository?

1. Not really, no. As nbering said, it is very hard to remove it from git history if you ever want to share it. Git is also not really meant to hold this kind of information.
2. Not much. The password only encrypts the key, so without the encrypted key, they can't really do anything.
3. A lot. They can create a version of your app with malware inside it and pass it as yours. However, without access to your appstore account, they may not be able to publish it directly. This still allows them to distribute it in other ways, eg. through different appstores or using the web. If they do gain access to your appstore account, they can publish their malware version as an update and users would have no way of knowing.
4. Yes and no. If you use manual builds, then you can just add the file into gitignore and distribute it in other ways. If you use autonomous builds, most git sites support special functionality for storing secrets.

Why not?

It’s all a matter of risk. My main argument against is that if you ever want to share that repository with someone who shouldn’t have the password, it’s really hard to remove the password from the git history. You need to rewrite all history to that point. So you’d have to rewrite all the commits, or squash to lose the history that contained the password. And you probably won’t remember to do that, so it’s safest just to leave them out.

Avoid Committing Secrets

To avoid storing secrets in git, I usually add the secret file to .gitignore. Since someone might need to know what was in the now-missing file, leave something like a gradle.properties.example file, with the redacted fields as "CHANGEME" or something like that, so anyone using the file will know how to create gradle.properties.

If possible, substitute from environment variables, so that you won't need to use a .example file. I personally recommend a tool like direnv which allows you to create a git ignored .envrc file, which can be used to set environment variables on a per-project basis. It automatically loads the environment variables from the terminal when you enter the directory. This doesn't always work well with graphical tools though, since their environment variables will be taken from the environment they were launched from.

Some graphical IDEs do support a concept like "targets" or "workspaces", which understands that some configuration options are configured in files that are checked in to source control, and others are specific to the files on your computer.

What's the risk?

If someone got ahold of your signing key, and the password, they could sign a malicious copy of your application.

If they managed to submit this copy to the app store, your users may automatically receive the malicious copy, without any notice that it was changed. Their device would trust it, because it was signed by your key.

Even without an app store submission, they could possibly sign a copy of the application and side-load it onto a device where the app was already installed, which would still trust it because it was signed by the same key.