Add a verifiable WDK build & driver-packaging CI pipeline

[epstomai]

What this does

Replaces the current .github/workflows/build.yml stub with a CI pipeline that
actually compiles the kernel driver and produces a verifiable, signing-ready
driver package — plus a small INF fix needed by modern InfVerif.

Included

• driver (x64) job: registers the WindowsKernelModeDriver10.0 toolset
  (works around it not being provisioned on the windows-2022 image), then
  builds the driver unsigned (SignMode=Off) and stages
  .sys / .inf / .cat, builds a submission .cab, writes
  SHA256SUMS.txt + BUILD-INFO.txt, and attaches build provenance.
• usermode (x64/x86) job: builds the SarAsio ASIO plugin.
• tools/Install-WdkBuildEnv.ps1, tools/Package-SarDriver.ps1: usable
  both locally and in CI.
• inf: PnpLockdown=1: required by InfVerif on recent WDKs.
• BUILDING.md: build/signing notes and tracked follow-ups.

Why

The previous workflow assumed a WDK on the runner and uploaded an MSI that was
never produced, so it could not build. This produces a reproducible, unsigned
package whose source↔binary link is verifiable (hashes + provenance) — the
prerequisite for free signing via Microsoft attestation / OSSign. Signing is
deliberately out of scope of the build.

Tested

Green end-to-end on windows-2022 (driver x64 + usermode x64/x86), artifacts
downloaded and verified; gh attestation verify on the .sys passes. Notable
environment finding: the image's WDK is 10.0.26100, and the .vcxproj's
pinned 10.0.22621.0 SDK ships without the matching kernel headers — so the
build auto-selects the SDK version that actually carries km\ntifs.h.

Intentionally deferred (see BUILDING.md)

ARM64 (needs an [Standard.NTARM64] INF model), Spectre mitigation for release
builds, the WiX MSI, and bumping a few actions off Node 20.

[epstomai]

Beyond CI: this unlocks a free, signed driver

This PR is deliberately scoped to building the driver and emitting a verifiable, unsigned package. It stops at unsigned on purpose, because that package is the input to the real prize:

OSSign signs open-source Windows drivers for free with EV + Microsoft attestation — they already do exactly this for a kernel driver, vadimgrn/usbip-win2 ("Signed binaries (EV) and attestation signed drivers via Microsoft"). With that, SAR could finally ship a .sys that loads on stock Windows 11 — no test-signing, no Secure Boot off, no broken anti-cheat, and no EV cert to buy.

The one catch: OSSign wants the project owner to apply. Everything else is already in place:

• ✅ OSI license (GPL-3.0), fully public source, real user base
• ✅ a verifiable build pipeline (this PR) — green end-to-end, with SHA256SUMS and a GitHub build-provenance attestation on the .sys
• ⬜ owner applies at ossign.org, then adds the signing glue

I've staged that glue so it's near-zero effort after approval: two workflows on the ossign branch (ossign-dispatch.yml + ossign-wait.yml), mirroring OSSign's own example-workflow and the usbip-win2 setup. They stay inactive until the OSSIGN_USER / OSSIGN_TOKEN secrets and a Signatures environment exist; the signed build runs on OSSign's side with their certificate.

Applying as the owner is ~30 minutes and the signed driver would live here in the official repo. Happy to help wire up the rest.