I don't get it. We can already do this: just have your server serve up XML, JSON, CSV, etc. Serving raw data with no code attached to it and disabling all extensions is something we already have. It's also not very useful.
The point of web applications is that you can quickly distribute an application that runs on a common platform to everyone at once. It's a very nice idea. It is also insecure to boot.
You are proposing two different changes. First, an enhanced ability of your web server to tell my browser which code is allowed and which code is not. This is good. This way, for example, my bank running on bank.example.com can tell my browser to not load any JavaScript code, or even any external resource from anywhere but bank.example.com. Now nobody can inject a JS file from evil.example.com. Fine-grained control over what the browser should and should not allow is a good thing. Controlling extensions is a bit different. I want my extensions to work. I want my ad blocker and my privacy guard to function even on sites like my bank's. In general, I would not want a site like Google to disable my ad blocker, that would be evil.
Now, if you are saying that you want to sign this application and distribute the signature to other services so that I as the user can verify that the application blob I got from your server has not been tempered with, then how do you go about updating your application? If you found a critical bug in your JavaScript code and fixed it, now you have to create a new application blob, a new signature, and distribute that signature to all these other services that are supposed to arbitrate whether you are delivering honest code. Notice that you and you alone still control the signatures. There is no external verification that you are not delivering evil code to me, I still have to trust you, personally. Adding a signature/checksum means that the code you delivered has not been tempered by a third party, but it says nothing about you. And the point of in-browser crypto is so that I don't have to trust you.
That's where the whole thing breaks down. If someone forces you to change your code, then update all the signatures and launch this code, then I still have no idea that it happened. So at best this might protect me from a malicious third party. But guess what? HTTPS already does that, and is a much simpler and proven solution.
In-browser crypto does not work, and will never work. There is no way to make it work. The web is not a platform where the client can treat the server as untrusted. Every time I see an attempt at this I cringe since someone clearly wasted a whole lot of effort thinking they finally cracked it. Keybase is probably the first place where I am not completely against it as they are using it as a demo of what your actual client would be doing. Then again, they could probably have just scrapped it completely and done the whole thing server-side without so much effort.
The alternative to what you are trying to achieve is this: every website is distributed as an open source application blob and a number of trusted third parties reviews the code before it gets published. These third parties each sign the the code with their private keys, showing that the believe the code to not be evil. The problem with this is that it completely undermines the central promise of the web application: instant deployment to all your users. This system is exactly what you have with Linux distributions' repositories. It work, it's secure, but it's slow.