It is possible to perform a single Argon2id for derivation of the AES-GCM key with a single salt identical for each file encrypted, using the same key for all files; and use a second salt, unique to each file, for AES-GCM itself. The drawbacks are

• Each file header must contain the two salts
• A failure of the salt generator (causing duplicated salts) has worse consequences.
• There is one more salt to generate

I recommend using the same salt $S$ for the same password $P$ in multiple encryptions, and a single Argon2id password-to-key derivation of $(P,S)$ into a single AES key $K$. That's best, because it allows to use higher cost parameters in Argon2id (e.g. that of the question's single key approach). That's safe, as long as a fresh and unique AES nonce $N_i$ is used for the AES-GCM encryption each file.

Each independently decipherable ciphertext file should contain (e.g. at start) the Argon2id parameters, $S$, and $N_i$, in order to allow decryption. Decryption can cache the last $K$, and reuse it when the inputs $(P,S)$ and parameters are unchanged in the next file.

Possible improvement: if it's wanted a unique key $K_i$ per file, that can be done by a secondary fast key derivation of $(K,N_i)$. That can be Argon2id with input and the lightest parameters possible $(p=1, m=8, t=1)$. This also limits to almost nothing the consequence of a repeated $N_i$ or counter overlap.

If no trusted CSPRNG is available to generate the $N_i$, that can be done by another secondary key derivation function, e.g. as Argon2id with input $(K,i)$ and the lightest different parameters possible, e.g. $(p=1, m=8, t=1, X=\mathtt{'N'})$