Love the idea! Here are few things that might be worth a closer look:
1) "... if someone can dump the indexdb data stored in your browser they can access your AES Key and impersonate the device ..." - I was surprised to read that index DB stores the AES key. Is that a "Shared Secret Session Key" negotiated via ECDH? If so, it should not be stored. Only the Public Key of the ToothPaste device (obtained during the "Pairing" process) should be stored in the browser's indexdb, preferably HMAC'ed or otherwise authenticated (via password-derived local client-only symmetric key which you already seem to be using)
2) "... ToothPaste allows encrypting this local data, along with saved Macros and Duckyscript scripts, using a Password + Argon2 derived encryption key ..." - make sure you are using random salt here, and deriving from (password+salt), not just (password). The salt should be stored in the plain text in the indexdb. Also, since this derivation runs in the browser (not in the MCU), try using Argon2id flavor of Argon to also make it memory-hard, not just compute-hard
3) from the animated gif demo, it looks like the BLE packets are being sent on every key stroke as you type. At the very least, you may leak your BitLocker password length. I would rather send the whole thing once user finished typing and pressed enter, or took more steps to obfuscate by padding with random dummy data and sending every 0.3 seconds
4) you never mention what MODE of AES are you using. I think you should be fine with GCM mode with random nonce, using "Message Number" as Associated Data (see next point)
5) you probably need a protection from "Replay" attack, i.e. encrypted BLE packet "replayed" by attacker. Could be done by ever increasing Message Number on a sender side, and receiver keeping track of the "last Message Number" and only accepting messages with higher number than "last Message Number" - for both directions you need 2 independent numbers. Also, Message Number is a good thing to put into Associated Data if you use AES GCM mode
6) every session should start from ECDH negotiating a brand new AES key - this way you dont have to deal with a long-living AES key, do not need to store it anywhere, and do not have a risk of using the same AES GCM key for too many messages or too much data