Windows users often set bare command names in the Ghostty config (`command = bash`) or pass them via `-e`, matching how they would on Linux/macOS. Today that fails because `CreateProcessW` does not do program search for `lpApplicationName` on its own. Thanks to @qwerasd205 for pointing out that passing `NULL` for `lpApplicationName` is exactly how Windows docs say to get program search for free. This PR does that: drop the explicit utf16 conversion for `lpApplicationName`, pass `null`, and make sure the program name is the first token of `lpCommandLine`. Windows then walks parent-app dir, CWD, system dirs, and PATH (and appends `.exe` for extensionless names). The child also sees its `argv[0]` exactly as we wrote it rather than a resolved absolute path, which is less surprising. Net change is +15 / -7 in `src/Command.zig`; no new helpers, no changes outside that file. The earlier version of this PR (which added PATH/PATHEXT handling in `internal_os.path.expand`) is obsoleted by this approach and has been force-pushed away. --- AI usage disclosure: developed with Claude Code (Claude Opus 4.7). Claude drafted the implementation based on my direction after @qwerasd205's review suggested the NULL-lpApplicationName approach. I reviewed the diff, built and verified it on the Windows GNU-ABI target, and am responsible for the code landing here. Part of the Win32 apprt upstreaming series (see discussion #2563 / mattn/ghostty#1).