Is it safe to store passwords on the client?
Yes, if done correctly. Depending on the client, they might have access to a secure storage offered by the operating system. Using this storage will allow you to store passwords/keys safely.
Does storing passwords on the client introduce vulnerabilities?
Yes. Knowing a password is always safer than writing something down. Malware on the client PC might be able to read it out, but this is turning into the realm of possibilities.
How should changing the password be implemented?
Downloading the data, decrypting it with the old key and re-encrypting it with the new key is not a good idea. It's not wrong, in the sense that it has some privacy impact, but it's not feasible for large data.
Imagine that your client has to deal with a 2 GB large file. First they would need to download 2 GB, then decrypt 2 GB, then encrypt 2 GB, then upload 2 GB again. And that's just for one file.
A much better approach would be to create two keys: A data encryption key (DEK) and a key encryption key (KEK).
The DEK is chosen randomly through a proper cryptographically secure pseudo-random generator. When implemented correctly, the DEK is impossible to crack. You can either choose one DEK per user, or one DEK per file.
The KEK is derived from the user-supplied password through a modern key-derivation function, such as Argon2d.
As their names imply, the DEK is used to encrypt the actual data. The KEK is used to encrypt the key. Given that the key is rather short (in comparison to the data you might encrypt) with 128 or 256 bit, decryption will be very fast.
When the user wants to change their password, all they have to do is decrypt the DEK with the old KEK, create a new KEK and use it to re-encrypt the DEK. The data never needs to be touched.
How to treat salts?
AES does not require salts. You have no benefit of adding salts. Salts are used to counter pre-calculation of hashes of weak passwords.
Please make sure you understand the reason why certain cryptographic measures exist before attempting to implement them yourself. I personally would suggest contacting a company of security consultants and have them review your cryptographic concept. They will be much better equipped to find flaws and nuances in it, as they will have full access to your concept, rather than limited information on a public site.
What if a user really forgets their password and we don't want to store it?
I would display a warning to the user that appears as follows:
Encrypting your data can lead to irreversible data loss if your key is lost!
<Our Company>
treats privacy very seriously. For this reason, we do not ever store your key on our servers. This means that if you forget your password, we have no way of recovering your data.
Please ensure that you use a safe passphrase when encrypting your data, which you will not forget. For more information please click here <link that will lead to some password best practices>