fix(build): emit GNU-compatible stack linker arg on windows-gnu

[silvaduartesuop]

Summary

• build.rs unconditionally emitted the MSVC-only /STACK:8388608 linker
  argument on every Windows target.
• On the x86_64-pc-windows-gnu toolchain the linker is GNU ld (via
  MinGW), which does not understand /STACK: and fails at the final link
  step — so cargo install is broken for MinGW users who don't have the
  MSVC linker installed.
• Fix: select the argument by target env — keep /STACK:8388608 for MSVC
  and emit the equivalent -Wl,--stack,8388608 for GNU. The 8 MiB stack
  reservation (needed so the clap command graph doesn't overflow the
  default 1 MiB stack at startup) is preserved on both toolchains.

Error before this change

error: linking with `x86_64-w64-mingw32-gcc` failed: exit code: 1
  = note: ld.exe: cannot find /STACK:8388608: No such file or directory
          collect2.exe: error: ld returned 1 exit status
error: could not compile `rtk` (bin "rtk") due to 1 previous error

Test plan

• cargo install / cargo build --release on x86_64-pc-windows-gnu
  now links cleanly (previously failed as above). Built the full crate
  with this exact change.
• Resulting rtk.exe starts correctly — rtk --version and
  rtk --help run without the stack overflow the reservation guards
  against, confirming the 8 MiB stack is still applied on GNU.
• cargo fmt -- --check build.rs is clean.
• MSVC path (/STACK:8388608) unchanged — verified by inspection; I
  don't have an MSVC toolchain on hand to build that path.

Note: this is a one-line build-script fix; there's no meaningful unit test
for target-env-conditional linker-arg emission, so no test file is added.
Happy to adjust the approach if you'd prefer a different mechanism (e.g. a
.cargo/config.toml per-target rustflags).

[CLAassistant]

All committers have signed the CLA.