What you’re saying is, there are no guarantees once you interact with code you have not written yourself? Yes you can use reflection to do some unsafe stuff. The problem is that the jvm, as you pointed out, knows nothing about nullable and not-null values. Once you interact with code at that level everything is nullable. Also you are using generics, so at runtime there is not even a difference between List<String> and List<Foo> due to the type erasure.
The question is how the language handles edge cases like this. Kotlin decided to build a system which is powerful and easy to use and is interoperable with Java. Are there edge cases, which can lead to NPEs? Yes, your example is one, another is accessing fields before the constructor is finished.
The problem is that kotlin is restricted by the JVM, which means that using java reflection there are always ways to set fields to null which should not be. But that is precisely what NPEs are for. They get thrown if you do something unsafe and it fails.
Kotlin never claimed that NPEs will never occur. It only claims that it will help prevent them when possible. No language can prevent all bugs, it can just help to reduce the number of bugs. In the end it is still up to the programmer.