Prevent and recover from wedged Wine-hosted processes

Prompted by a real incident: an MSBuild node-reuse worker (its own
/nodeReuse:true default) survived a build getting interrupted, came
back deadlocked, and got reused by the next `msbuild` invocation -
which then failed with a confusing, unrelated-looking
`System.TypeLoadException` on Microsoft.VisualStudio.Telemetry on
every call for hours, until the stale process was killed by hand.
That's exactly the "unrelated blocker" noted in this repo's own
earlier session notes (CLAUDE.md) while debugging a real project's
build - it wasn't a missing dependency, it was a corrupted reused
process.

Two changes:

- vintner now forces /nodeReuse:false on every msbuild invocation
  (unless the caller already passed their own /nodeReuse or /nr
  switch), so a wedged worker can never poison a later, unrelated
  build in the first place. Costs each invocation the couple-hundred-
  ms/node startup time node reuse exists to save.

- VINTNER_TIMEOUT (a duration string, e.g. "30m") bounds how long any
  single tool invocation is allowed to run, for the case something
  wedges that isn't MSBuild-specific. Every exec.Command site in
  internal/wrapper now goes through a shared newToolCommand
  constructor that, when the timeout is set, kills the *whole*
  process group (not just the immediate `wine` process - a wedged
  child surviving under it is exactly the scenario this needs to
  reach) via a context deadline, and reports a clear "timed out after
  Xm" message (exit 124, matching the timeout(1) convention) instead
  of a bare "signal: killed". Unset by default - every real build
  observed stays unbounded, matching Windows' own behavior.

Verified end-to-end, not just at the unit level: a real `sleep 30`
through the `cmd` native wrapper with VINTNER_TIMEOUT=1s was killed
within the deadline and reported the timeout clearly (exit 124); a
real `cl` invocation with the same 1s timeout finished normally
(0.26s) without being mistaken for a hang.

README.md

@@ -23,6 +23,7 @@ approach: download the real MSVC/WinSDK, wrap the compiler under Wine.
 - [Commands](#commands)
 - [Building drivers (WDK)](#building-drivers-wdk)
 - [Building against D3DX9 (DirectX SDK)](#building-against-d3dx9-directx-sdk)
+- [Automated/scripted builds](#automatedscripted-builds)
 - [Language](#language)
 - [Shell completion](#shell-completion)
 - [Using clang-cl/lld-link instead of Wine](#using-clang-cllld-link-instead-of-wine)
@@ -164,6 +165,26 @@ Point your project's `IncludePath`/`LibraryPath` at
 Requires `cabextract` on `PATH` (the installer is a self-extracting CAB
 archive).
 
+## Automated/scripted builds
+
+Every tool invocation runs unbounded by default, same as the real thing on
+Windows. Set `VINTNER_TIMEOUT` (a `time.ParseDuration` string, e.g. `30m`,
+`2h`) to have vintner kill and fail a build that runs longer than that
+instead of hanging forever - meant for CI and other unattended callers, not
+interactive use. This guards against one confirmed failure mode: an
+MSBuild node-reuse worker (`/nodeReuse:true` is MSBuild's own default) can
+survive its parent process under Wine and, if a prior build was
+interrupted mid-compile, come back wedged - reused by the next `msbuild`
+call and failing every subsequent build with a confusing, unrelated-looking
+error, indefinitely, until it's killed by hand. vintner already forces
+`/nodeReuse:false` on every `msbuild` invocation to prevent this in the
+first place; `VINTNER_TIMEOUT` is the backstop for whatever else might
+wedge under Wine that isn't MSBuild-specific.
+
+```bash
+VINTNER_TIMEOUT=30m msbuild MyProject.sln
+```
+
 ## Language
 
 CLI text (usage, progress lines, prompts) defaults to English. Set