I'm prototyping an app that uses client-side password hashing in order to hide the "real" account password from a server (the server hashes any recieved password anyway, so no plaintext records in the database). It seem to be a controversial thing to do but I didn't find any convincing arguments against it (I'm new to cryptography so please correct me if I'm wrong). 

I'm trying to figure out what would be an appropriate salt for Argon2i. Many implementations generate random salt by default but it won't allow users to log in again because using new salt produces new hash. That's why I can't avoid using deterministic salt.

My understanding is: each salt value is better to be globally unique for each user so it seems like an email address could make an OK salt in a sense that it's unique, but not globally. Email + password would certainly lower the chances of a collision but some users might have the same passwords in many apps. I'm thinking about sha256(app name + email). Would it make a good salt?

My main question is about the implications of using a deterministic salt in general. Does it make the resulting hashes easier to crack? And if it's OK, what would be an appropriate way to generate such a salt?

Another related thing I'm wondering about is how easy is it to crack the hash and not the password itself? Let's say I use Argon2 to hash a password and use the same exact password as hash (argon2(pwd = "foobar", salt = sha256("foobar")). Would it help an attacker to reveal that password by any method except using a rainbow table?

This is expected behavior since 7zip uses Cipher Block Chaining (CBC) mode for encryption. For which you need the Initialization Vector (IV) to be unique and unpredictable.
It was using 64-bit IV but fortunately, that was changed to 128;

Encryption strength for 7z archives was increased: the size of random initialization vector was increased from 64-bit to 128-bit,
and the pseudo-random number generator was improved.

If the encryption of the same file results in the same ciphertext then we will be thought that there is a problem with the IV generation. Hopefully, from here we see that there is not.
Note 1: 7zip uses $2^{19}$-times iterated SHA256 to derive the AES-256 key from passwords. This is not safe from massive parallelization. A password with high entropy like diceware is recommended.
Note 2: The first comment under question claims that CBC mode of operations has IND-CCA actually it can't, it has IND-CPA. See the seminal work of Rogaway on modes Evaluation of Some Blockcipher Modes of Operation
