"I need to access the key from the js environment without the user entering an encryption password"
As @mti2935 points out, it is unencrypted in major browsers, and basically impossible at this point in time to achieve this goal without storing the key-encryption-key 'somewhere else'. I second that observation (for Firefox up to about 2019 at least, last time I looked at indexed-db).
Here is a possibility that wouldn't require you to store your long-term key un-encrypted: it won't allow your user to get away with 'doing nothing' if they want something more closely resembling security...
input type=password field, which possibly the user might choose to 'remember' in their password manager^ - this becomes the long-term key input
- this long-term key is then derived using a built-in WebCrypto PBKDF2, and used to decrypt the application symmetric key stored in indexed-db - you might wish to use another pbkdf such as Libsodium's Argon2 implementation,
^ If the user chooses to store the long-term key input (as a 'saved password') in their browser, then they won't need to type this again. It will be stored encrypted, and possibly further secured if the user applies a password for the internal password database key.
One obvious downside to this is potentially the repeated use of the pbkdf, which may interfere with the user's experience, depending on how 'hard' you tune it. Another is the static nature of your long term key, and what would be required if the user wishes to update any of the inputs. Since you don't specify how you're using the symmetric key that you wan't to store, I'll assume it's to access other encrypted data stored locally. (If you edit your question to clarify, I might update this answer.)
As to how the initial long-term key input is derived, you might consider having the user provide additional material via a key-file that they hold. You would then take the secure hash of any key-file that they choose, using a local file picker and the built-in keyed hashing functions.