V panic: unable to join thread after rapid navigation — standalone mode, Windows

After starting the app and clicking navigation links rapidly for a few seconds, the server crashes with:

`V panic: unable to join thread
v hash: 49bade5
pid: 0000000000002154
tid: 00000000000051e4
print_backtrace_skipping_top_frames is not implemented`

The page freezes across all browsers simultaneously. The only fix is restarting the server. The crash is deterministic — it always happens after enough rapid requests.

**Environment**
- OS: Windows.
- V version: V 0.5.0 49bade5.
- Mantis version: latest master.
- Mode: Standalone (no reverse proxy).

**To reproduce**
- Create a standard Mantis app with a few` route.get` routes and a view per route.
- Configure with cpus: 1 (or any value — tested up to cpus: 8, same result).
- Start the app with `v -cc gcc watch run .` .
- Open in browser and click navigation links rapidly and repeatedly.
- After several clicks, the server panics and the page freezes.

**What was ruled out**
Controllers use only immutable `const` data — no shared mutable state.
Increasing cpus (tested 1, 4, 8) does not prevent or delay the crash.
The crash reproduces across Chrome, Firefox, Opera and Edge simultaneously.
`print_backtrace_skipping_top_frames` is not implemented prevents getting a stack trace on Windows.

**Expected behavior**
The server should handle rapid sequential or concurrent requests without panicking.

**Suspected cause**
The unable to join thread panic suggests a thread lifecycle issue in Mantis's standalone request handling loop — a spawned thread likely exits or enters a bad state before .wait() is called on it, causing the V runtime to panic. This may be a Windows-specific issue in how V manages thread joining under load.