I'm aware of chosen plaintext attacks against a reused IV, but at rest the attacker is just an observer.

Offhand, the only problem I see with a fixed IV for string storage encryption is that if two passwords match in the first kB bits, were B is the AES blocksize and k is a positive integer, and assuming CBC mode, the attacker can see this.

Are there worse holes open to someone who is just observing at rest data?

That reminds me of something I've wondered about. How about AES in CBC mode with a fixed IV, but the plaintext is prepended with a hash of the entire message first, using a hash of at least the size of the AES block?

In effect, if the hash output is the size of one AES block, that makes the hash encrypted with the key using the fixed IV be the IV for the encryption of the plaintext.

That should effectively give each plaintext its own IV derived from its hash and the key, but conveniently stores this in the output string so you don't have to have separate IV storage. This could be convenient in applications where you adding encryption to something existing, such as changing a DB to hold encrypted values instead of plaintext values in certain columns, but where you are reluctant to add new fields, such as adding a column for the IVs.

For some storage applications, you want to support checking if a given plaintext is already stored and return the index of that prior instance in that case rather than store a new instance, so if you use random IVs then you need to separately store a hash of each item, and if that is not encrypted that could be a vulnerability if someone stole a copy of the DB if the plaintexts are small (like credit card numbers).

The prepend the hash to the plaintext and use a fixed IV on that provides the reproducibility for duplicate checking, without obviously exposing the hash to someone who steals the DB, while effectively encrypting the actual plaintext using a pseudorandom IV derived from the AES key and the hash.

But I've not seen it used or described, so don't know if it is an OK approach.

The code uses CFB mode, so fixing the IV results in a constant first block, which gets XOR'd with the first plaintext blocks to make the first ciphertext blocks. So knowing one plaintext gives you access to all first plaintext blocks.

One problem with your proposal is that for CPA security cuts the security level of the scheme in half. For an n-bit hash about 2^(n/2) operations are required to find a collision, and given a collision you break CPA security.