The whole point of a salt is to be unique to a set-password operation, so that attackers can't reuse work when they target multiple accounts (multiple users on the same server, multiple servers, or both). Using the password as the salt completely defeats the purpose.

The salt does not need to be unguessable or secret. The reason it's almost always a long-ish random string is to be statistically unique (in the literal sense), not to be securely unique: it's random so that the chance of two set-passwords using the same salt accidentally is negligible, not so that an adversary cannot guess it. A unique server name plus thread identifier plus timestamp would work as well, but that's not commonly done because it's hard to ensure you get a unique string this way in all environments (e.g. on a cloned virtual machine).

Most libraries automatically generate a random salt during the set-password operation and store the salt with other metadata together with the output of the password hashing function. In most programming environments, you'd need to do some extra processing to force a different salt during the set-password and check-password operations. Do not do this extra processing: it would add complexity, only to reduce security even if implemented perfectly.

A password with 64 characters on a 62-character alphabet has about 381 bits of entropy, which is overkill: any data that it protects, or its transmission in communication, would at most be protected by a 256-bit key. 43 characters would give you 256 bits. 20 characters would give you 119 bits. With a password that long (and randomly generated, otherwise length is irrelevant), you don't actually need a password hashing mechanism: the purpose of password hashing mechanisms as opposed to ordinary hashing is to make guessing harder, but guessing a 119-bit secret is infeasible in the first place. So from a theoretical perspective, because your password is already high-entropy, using Argon2i or any other password hashing function with a defective salt won't actually reduce the security of your system. But you still shouldn't do it, both in case the system is ever used with a “normal” (lower-entropy) password and because it would increase the implementation complexity.

The whole point of a salt is to be unique to a set-password operation, so that attackers can't reuse work when they target multiple accounts (multiple users on the same server, multiple servers, or both). Using the password as the salt completely defeats the purpose.

The salt does not need to be unguessable or secret. The reason it's almost always a long-ish random string is to be statistically unique (in the literal sense), not to be securely unique: it's random so that the chance of two set-passwords using the same salt accidentally is negligible, not so that an adversary cannot guess it. A unique server name plus thread identifier plus timestamp would work as well, but that's not commonly done because it's hard to ensure you get a unique string this way in all environments (e.g. on a cloned virtual machine).

Most libraries automatically generate a random salt during the set-password operation and store the salt with other metadata together with the output of the password hashing function. In most programming environments, you'd need to do some extra processing to force a different salt during the set-password and check-password operations, and to change the storage format so that the salt is not stored (otherwise you'd just be storing your password in plain text). Do not do this extra processing: it would add complexity, only to reduce security even if implemented perfectly.

A password with 64 characters on a 62-character alphabet has about 381 bits of entropy, which is overkill: any data that it protects, or its transmission in communication, would at most be protected by a 256-bit key. 43 characters would give you 256 bits. 20 characters would give you 119 bits. With a password that long (and randomly generated, otherwise length is irrelevant), you don't actually need a password hashing mechanism: the purpose of password hashing mechanisms as opposed to ordinary hashing is to make guessing harder, but guessing a 119-bit secret is infeasible in the first place. So from a theoretical perspective, because your password is already high-entropy, using Argon2i or any other password hashing function with a defective salt won't actually reduce the security of your system. But you still shouldn't do it, both in case the system is ever used with a “normal” (lower-entropy) password and because it would increase the implementation complexity.