v1.17.1-OpenVino

Intel_NPU branch — synced to upstream v1.17.1

• Fixed: the ONNX Runtime backend (USE_BACKEND=ONNX) failed to compile after syncing with
  upstream v1.17.1, because upstream's TensorRT rework introduced its own onnxmodelbuilder.cpp
  under the same filename as this fork's ONNX-Runtime-specific one. The backend has been rewritten
  on top of the new shared builder (matching the design of unmerged upstream PR lightvector#1222) and is
  working again, verified on real Intel NPU + iGPU hardware.
• New: NPU + iGPU hybrid inference — run the neural net across both an Intel NPU and integrated
  GPU at the same time by pinning separate backend threads to each device
  (onnxOpenVINODeviceTypeThread<N>).
• New: per-server-thread batch size override (nnMaxBatchSizeThread<N>), so a hybrid NPU+iGPU
  setup can use batch size 1 on the NPU while giving the iGPU a larger batch — this is generic and
  works for any backend, not just ONNX.
• New: onnxSkipScale8, onnxOpenVINOPrecision/NumStreams/NumOfThreads/ModelPriority,
  onnxOpenVINODeviceConfig_<NPU|GPU|CPU>_<Option>, onnxTransformerNHWC config keys for finer
  OpenVINO tuning.
• New: NPU-friendly exact-board graph build (onnxOpenVINONPUExactBoard, default false).
  When the session targets an NPU device, the backend emits a mask-free exact-board graph — the
  InputMask path and all attention mask-bias adds are dropped (they are mathematical no-ops when
  the board exactly matches the network size). Combined with batch 1 and the new compiler options
  below, this takes b11-class v17 models on Intel NPU from 2.73 to 4.87 visits/s (+78%), stable
  through multi-hour runs. ⚠️ Only enable it for fixed-board-size workloads (GTP play, benchmark,
  match — the evaluator is always created for the exact size in use). Never enable it for
  mixed-size analysis (e.g. analyzing 13x13 games on a 19x19 model): without the mask, padded
  boards are indistinguishable from real ones and evaluations are silently wrong.
• New: onnxOpenVINOLoadConfig — passes arbitrary OpenVINO device config (JSON) through to
  ONNX Runtime's load_config provider option. The shipped NPU configs use it for
  optimization-level=2 + performance-hint-override=latency (measured faster;
  NPU_TURBO deliberately omitted — it was slower in testing).
• Fixed: the OpenVINO compile cache was never created (every startup paid a full NPU recompile).
  Compiled blobs now cache to KataGo's standard data dir by default
  (<katago.exe dir>/KataGoData/openvino_cache on Windows, ~/.katago/openvino_cache on Linux;
  onnxOpenVINOCacheDir still overrides).
• Improved: .bin.gz KataGo models now load directly through the ONNX backend without an
  exportonnx conversion step; the export command still exists for producing a portable raw .onnx
  file if you want one.
• Build system: ONNX backend's protobuf dependency simplified (one less vcpkg package needed);
  Windows vcpkg triplet switched to x64-windows-static-md to avoid a rare heap-corruption issue
  from duplicate abseil_dll.dll instances.

⚠️ Known issues on Intel NPU (important, read before using NPU)

• v17 models (b11/b40-class, with attention layers) are unstable on Intel NPU with batch > 1.
  Root cause is in Intel's NPU compiler/driver, not KataGo (reproduced with pure OpenVINO, no
  KataGo code involved; also present with the newest NPU driver 32.0.100.4841):
  • batch ≥ 6: model compilation hangs forever;
  • batch varying 1–5: intermittent ZE_RESULT_ERROR_DEVICE_LOST during inference.
    Both are avoided by pinning batch to 1 — the shipped gtp_npu.cfg now sets nnMaxBatchSize = 1
    (NPU gains no throughput from larger batches anyway: its small MAC array is saturated at batch 1,
    so batch N costs ~N× latency for ~zero gain). Do not run benchmark autotune on NPU — it
    scales up to 32 threads (batch 32) and walks straight into the compile hang; use fixed -threads.
    An upstream report to openvinotoolkit/openvino with a pure-OpenVINO repro is being filed.
• For these large v17 models the iGPU may be faster than the NPU. onnxOpenVINODeviceType = GPU is the
  recommended config for them; NPU/hybrid mainly makes sense for smaller models or
  power-constrained scenarios.
• Raw .onnx model loading is currently broken (crashes even with onnxProvider = cpu); load
  .bin.gz models directly instead — that path is unaffected.