The main problem is, that the "login" password for the web vault is the same as the password for encryption. In theory this is safe, as the password is hashed in the browser and not transferred to the client. But there could easily be a bug, that transfers the password in cleartext. The same principle applies when using any of the apps.
I think there are two different aspects to your very valid concern. Both worry me.
A password manager company might provide an in-browser application to access the cloud-based vault
I do think of the in-browser application as a hardened application, similar in security to the desktop application. When I access xyz.1password.com (I'M NOT ADVOCATING 1PASSWORD), a Javascript application is delivered to my browser and starts running. From then on, all of my interactions are with that Javascript program, in the same way they would be when I'm using the desktop application. My login credentials are only being directly provided to that local application. (wishful thinking?)
I can think of two significant, additional risks to browser applications as compared to desktop ones.
1 - Bugs or viruses in the browser, itself. Yeah, that's serious. People use all sorts of browsers. It's hard to know which ones to trust.
2 - Browser applications are delivered to one's machine far more often than a desktop applications. For example, if you clear your browser cache, you browser has to get the application again. On the other hand, a desktop application is only delivered when originally downloaded and subsequently updated to later versions. So, I guess you could say that a browser application has an elevated supply-chain vulnerability.
Browser extensions have similar risks to full blown web applications. Unfortunately, browser extensions are a risk even if you only have local vaults. Heck, for that matter, all software is a risk.
Vaults are stored in the cloud
Even though the ability to unlock the vault is completely local for a "TNO - trust no one" solution, there has to be some way for the user to supply credentials to the server to be able retrieve the vault. At the same time, those credentials presented to the server must not be usable by the server to unlock the vault. This is an easily solved cryptographic challenge. It is the same challenge for a browser-based application as it is for a desktop application.
The risk here is complexity. The challenge of safely delivering the vault (or communicating at all with any server) goes away when you just have local vaults. So, bugs and design flaws are a more serious concern. As you said, if a bug allows the application to deliver credentials to the server that can also unlock the vault, then that would be very serious.
However, using a cloud service like Dropbox to store your vault is probably much worse with respect to vault access (not vault unlocking). Dropbox uses a simple password. As a contrasting example, 1Password forces your password to be unbearably complex. But, they split it up into two pieces. One piece is the master password that you memorize and type in over and over again. The other piece, the secret key, is required once per machine (or browser), is a randomly generated 32 character string, and retained by the machine to be used on your behalf. I don't know how other cloud storage password managers do this.
Please - I'm not advocating for 1Password. I'm not saying they do a better job than anyone else at dealing with the complexities of cloud storage.