JVM was originally designed to run as a single thread because of bunch of factors that were relevant at that time:

It was originally designed to run on embedded-ish platforms without any real OS. And in such an environment it makes perfect sense to do threading at a VM level (also implementing it that way is not that hard for bytecode interpreter, as additional bonus you don't have to think about issues like concurrent accesses to internal structures of the VM and stopping the world for GC).

The time when Java was designed more or less overlaps the time when first "mainstream" operating systems with OS-level threads (ie. Windows NT and Solaris) were also designed, so it could not exactly assume that underlying target supports OS-level threads. For client platforms you had Classic MacOS and 16bit windows both with multitasking models where the concept of thread does not really make sense and Windows 95 with NT-derived Win32 API with real threads. In server space you had various Unix flavors that migh or might not have OS-level threads but these that had threads had mutually incompatible APIs and then you have "Network Operating Systems" (eg. Netware) that were marketed in a way that presented absence of real multitasking as an "performance benefit".

In this 90's environment typical large application that was intended to be portable included somewhat extensive platform abstraction library that more often than not included implementation of something similar to green threads (with POSIX standartizing ucontext_t and friends as an portable-ish API to built such a thing on). You can probably find remnants of such an layer in Firefox code to this day (and probably in other large originally proprietary software packages that were then opensourced).

I found the StackOverflow accepted answer to be a very clear explanation, it summarizes and re-iterates what matters: "With Virtual Threads, multiple virtual threads can run on multiple native threads (n:m mapping)"