CTemplar, “the only really secure end-to-end encrypted webmail”, can’t be trusted (as any other)

It’s silly.
CTemplar is a recent player in “secure end-to-end encrypted webmail” field.
They claim: «Our mission is to provide an anonymous E2EE (End to End Encrypted) email. No one except you and your recipient can read the contents of your emails, not even us» (archived).
They also claim: «In November of 2018, Professor Kobeissi revealed that if JavaScript is required for encryption, it can also be used to hack users who use end-to-end encrypted email services. How Did We Solve This With Checksums? The checksums, released on GitHub after every update, allows our users to quickly compare the code served to their browser, with the code hosted on GitHub within 15-30 seconds. Usually, comparing code can take hours or days. With checksums, you can do it in seconds» (archived – you can read Kobeissi findings here).
They give instructions about how to “quickly compare the code served to their [the users’] browser, with the code hosted on GitHub within 15-30 seconds” here (archived).
But the fact is: all users should spend “15-30 seconds” (I spent at least one minute when trying) every time they access any URL serving CTemplar webmail service on https://mail.ctemplar.com/, in order to maybe feel certain (and currently not to be certain: see below) that the Javascript code running in their browsers is actually the same as that published on github – which is evidently totally impractical for anyone.
And the fact is: when I tried, the login page to their webmail service (archived) was not the same as the login page they published on github (archived): it sourced some more Javascript code at the end.

CTemplar login page source

And the fact is: would have it been the same, I still could not have been certain the Javascript code running in my browser was the same as that published on github, since for example the browser-compatibility.js file (among many other files the index.html sourced) had two integrity checksums.

CTemplar login page source (2)

The checksum of the browser-compatibility.js file published on github actually matched the first one specified in the integrity attribute for browser-compatibility.js on the page I got from the server, but I actually could have received the other, unknown and different browser-compatibility.js that is not published on github and that matches the second checksum (the problem here is that SRI allows to specify more than one checksum for a given file).
What does this all mean?
This means and confirms that Services offering end-to-end encryption through web sites can’t be trusted.