While I have no inspected OP's use of cryptographic primitives (comments seem to indicate that OP has not made proper use of RNGs), do note that authenticated encryption modes, or rather authentication in general, serves a purpose that is not really relevant for a password manager.

That is, I do not find an adversary replacing, trashing, or performing zero-knowledge modifications on my credentials to be an attack vector that has any importance. What would the adversary gain from tampering with passwords (which authentication would protect against) without the ability to read them (which encryption takes care of)? It would mean that I lose access to, say, my online bank account, but this is just as well done by deleting the database without tampering.

My only interest would appear to be to maintain secrecy of my password database so that an adversary does not obtain my access to my passwords, which does not require authentication.

That does not mean that using AES-GCM would hurt, but it also wouldn't really add any notable benefits here. Unless someone else can think of a scenario where authentication would be needed?

> That is, I do not find an adversary replacing, trashing, or performing zero-knowledge modifications on my credentials to be an attack vector that has any importance.

I wanted to pick this sentence out to point out the general most important thing that any project that claims to be security-oriented should have: A documented threat model. You should know exactly what this thing does try to prevent, and what it explicitly does not try to prevent. A lack of one should be taken as a sign that it isn't ready for any use that requires security.

Hear, hear! The concept of documented threat models is far too rarely used. And, to be frank, the threat model needs to be in place before you design the product.

Scenarios where I can tamper with the password database, but not e.g. add a keylogger to your system are of course somewhat limited (although people love to put the database in sync services like Dropbox) Not just the passwords, the bigger data structure should be authenticated. Some possible scenarios:

I can copy the encrypted password to another entry that's easier to compromise: E.g. you might be suspicious of a phishing mail targetting your bank account, but are you paying the same attention to a faked message from a random webforum you use? (Or maybe an attacker can hack said forum a lot easier than your bank)

For a more featureful password manager that has gained a browser plugin that matches on URLs, I can now add an entry for my phishing URL to the password manager.

As a principle secure things should pay attention to details and follow best practice. For me,I'm more concerned about lack of kdf and rng. But it all depends on how the program treats the data after decryption and how your password db is stored and transported. You have to also keep in mind that users keep other secrets as well in a password manager,not just passwords. You're giving the public a secure secret storage mechanism,you should follow best practices because you don't know exactly what type of attackers your users face ,what type of specific data/creds they store in it or how they transport it.

You need to be more careful with your reasoning. It's not always the case that a MAC simply prevents "replacing, trashing, or performing zero-knowledge modifications" on your data. It can be the case that you cannot retain confidentiality without integrity; MACs prevent chosen-ciphertext attacks.

While correct that authentication can prevent chosen-ciphertext, I do not see how such an attack could be relevant against an offline password manager. I ignored it for that reason.

There is also the Efail pattern of attacks, where malleable ciphertext is used to inject active controlled plaintext (HTML tags, different URLs, etc) that exfiltrate the rest of plaintext. Can you rule that out as well?

There's a reason some people call this "the cryptographic doom principle".

Corruption detection is the main one, but it is indeed not a security issue

Indeed, and if corruption detection is your goal, a checksum is the proper solution. Authentication is an expensive and roundabout way to do simple corruption detection.