windows: link MSVC release binaries with static CRT (#22905)

## Why

Windows release artifacts currently import `VCRUNTIME140.dll` and
`VCRUNTIME140_1.dll`. That becomes observable on clean Windows machines
that do not already have the VC++ runtime available globally:

- Desktop Store launches can fail after the app relocates `codex.exe`
out of `WindowsApps`, which means an MSIX-level VCLibs dependency does
not protect the relocated CLI/app-server process.
- The npm CLI path reproduces the same missing-DLL startup failure when
`System32\vcruntime140_1.dll` is hidden and `PATH` is stripped of
incidental fallback copies.

In that setup, the existing Windows binary exits with `0xC0000135` /
`-1073741515` before Codex code runs.

## What changed

- Add `-C target-feature=+crt-static` to the existing MSVC-only Cargo
rustflags in `codex-rs/.cargo/config.toml`.
- Preserve the existing `/STACK:8388608` linker setting in the same
target block.

This keeps the change scoped to Windows MSVC builds and avoids altering
non-Windows or GNU target behavior.

## Verification

I built an x64 Windows release probe with static CRT linkage and the
normal 8 MiB stack reserve, then verified:

- `dumpbin /dependents codex.exe` no longer reports `VCRUNTIME140.dll`
or `VCRUNTIME140_1.dll`.
- `dumpbin /headers codex.exe` reports `800000 size of stack reserve`.
- With `System32\vcruntime140_1.dll` hidden and `PATH` stripped to
Windows system directories only:
  - the old npm CLI path exits `-1073741515`
- the rebuilt static-CRT `codex.exe --version` succeeds with exit code
`0`
  - the rebuilt TUI starts successfully

I also confirmed `codex.exe app-server --listen ws://127.0.0.1:0` starts
and binds normally with the static-CRT artifact.

codex-rs/.cargo/config.toml

@@ -1,5 +1,5 @@
 [target.'cfg(all(windows, target_env = "msvc"))']
-rustflags = ["-C", "link-arg=/STACK:8388608"]
+rustflags = ["-C", "link-arg=/STACK:8388608", "-C", "target-feature=+crt-static"]
 
 # MSVC emits a warning about code that may trip "Cortex-A53 MPCore processor bug #843419" (see
 # https://developer.arm.com/documentation/epm048406/latest) which is sometimes emitted by LLVM.