[BUG] Unsafe std::env::remove_var in WSL2 workaround

Bug Report

Platform

Linux (WSL2 specifically), potentially macOS

Current Behavior

In apps/desktop/src/main.rs:28-30, the code uses unsafe { std::env::remove_var("WAYLAND_DISPLAY") } to work around a GPUI 0.2.2 WSLg issue:

unsafe {
    std::env::remove_var("WAYLAND_DISPLAY");
}

Problems

1. Thread-safety violation: std::env::remove_var is NOT thread-safe. If any other thread reads the environment concurrently (common in async runtimes), this causes undefined behavior.
2. Fragile assumption: The comment claims "this is the first statement in main" but any future code added above breaks this guarantee.
3. Process-wide side effect: Modifies environment for the entire process, affecting child processes and other threads.

Expected Behavior

Use thread-safe alternatives:

• std::env::set_var("WAYLAND_DISPLAY", "") to unset (still not fully thread-safe but safer)
• Or better: configure the GPUI/Winit window builder to use X11 explicitly via WAYLAND_DISPLAY="" cargo run at process spawn
• Or set the env var before spawning the process via Command::env_remove("WAYLAND_DISPLAY")

Steps To Reproduce

1. Run on WSL2 with both X11 and Wayland configured
2. App may crash or behave unpredictably under concurrent env access

Recurrence Probability

Sometimes - race condition dependent

Additional Context

This is a soundness issue in Rust. The unsafe block doesn't actually make the operation safe - it just tells the compiler you've verified safety, which isn't true here.

Start in apps/desktop/src/main.rs:28-30 and inspect how the application starts and how the GPUI 0.2.2 WSLg workaround is applied. Determine a thread-safe way to handle WAYLAND_DISPLAY without an unsafe process-wide mutation, then verify the behavior on WSL2 and macOS where applicable.