bug: shouldLaunchBrowser() returns true on WSL2 because WSLg sets DISPLAY/WAYLAND_DISPLAY

Problem

On WSL2 with WSLg enabled (the default on Windows 11), shouldLaunchBrowser() in workspace-server/src/utils/secure-browser-launcher.ts returns true because WSLg pre-populates DISPLAY and WAYLAND_DISPLAY. The server then takes the GUI path and calls open() / xdg-open for OAuth, which from WSL is unreliable — typically no browser the user is actually watching surfaces, and getAuthenticatedClient() ends up stalling until its ~5-minute timeout.

The headless flow added in #227 is the correct path for WSL2, but it is never reached because WSL is misclassified as GUI-capable.

Reproduce

1. Run the MCP server inside WSL2 on Windows 11 (WSLg defaults).
2. Confirm echo \$DISPLAY and echo \$WAYLAND_DISPLAY both return values.
3. Clear credentials and trigger any tool that requires fresh auth (e.g. gmail.search).
4. The server takes the GUI-launch branch and hangs / times out instead of returning the headless OAuth URL.

Proposed fix

In shouldLaunchBrowser(), treat WSL as headless by checking for WSL_DISTRO_NAME or WSL_INTEROP (set by WSL2 but not by native Linux). This routes WSL users through the existing headless flow.

Happy to send a small PR (one function, plus a test) if the maintainers are open to this approach.

Environment

• WSL2 on Windows 11 (WSLg defaults)
• Latest `main`

Start in workspace-server/src/utils/secure-browser-launcher.ts at shouldLaunchBrowser(), then review the headless flow introduced in issue #227. Use the WSL2 environment variables described in the issue to verify that WSL takes the headless OAuth path and add the corresponding test; done means WSL no longer uses open() or xdg-open for authentication.