ways corpus: does calibration's batch_similarity abort on Windows via Stdio::null()?

[aaronsb]

Split out of the review on #354 — a real question, deliberately not fixed blind.

The inconsistency

tools/ways-cli/src/cmd/corpus.rs spawns way-embed from two places, with two different stderr policies:

• auto_embed → run_generate carries a Windows-specific workaround, with this comment:

  On Windows, Stdio::null() for the NUL device can cause MSVC C runtime to abort the child process. Use Stdio::inherit() on Windows instead.

• fit_calibration → batch_similarity uses an unconditional Stdio::null(), on every platform including Windows. It has never had the workaround.

The question

If the auto_embed comment is accurate, then batch_similarity's child is aborted by the MSVC runtime on Windows — which would mean per-model calibration (ADR-156) silently never fits on Windows. batch_similarity returns None on any failure, and fit_lane maps None to "lane left uncalibrated", so this would degrade quietly with no error, exactly the failure shape the null-stderr policy was hiding elsewhere.

Either:

1. The comment is right, and this is a live Windows bug that silently disables calibration; or
2. The comment is stale/overcautious, and run_generate's Windows inherit() is unnecessary noise (Windows users currently see llama.cpp's model-load chatter on every corpus build).

Both can't be true. Worth resolving on an actual Windows box.

Why it wasn't fixed in #354

#354 adds --verbose. Changing Windows stderr behavior there would have been an unrelated, unverifiable change smuggled into a diagnostic PR. That PR now preserves the prior behavior exactly (null() when quiet, on all platforms) and only adds the inherit() case under --verbose.

How to check

On Windows, run ways corpus --verbose and look for the two calibration[en] / calibration[multi] lines. If they're absent — or lane[...] prints with no calibration[...] following it — the child died and calibration is silently off.