docs: bash-on-Windows is proven broken (WSL as local system), with the log

The 58f4832 Windows run completed and failed, but not on the bootstrap: its
Windows steps still used `shell: bash`, and on winvm-builder bash resolves to
WSL, which refuses to run under the runner's service account:

  Running WSL as local system is not supported.
  Error code: Bash/WSL_E_LOCAL_SYSTEM_NOT_SUPPORTED
  ##[error]Process completed with exit code 1.

The step died on the shell without ever invoking cmake. So the PowerShell
rewrite in 524e78c -- which was written pre-emptively from reading the
workflow back, on the reasoning that bash "cannot be assumed present" -- is
now confirmed necessary by a real log rather than by argument. It is still
unproven in the other direction: no completed run has yet included it.

Equally important for reading the record correctly: this failure says nothing
about the OBS::w32-pthreads blocker. That result stands on edb0c02 alone, and
the README now says so explicitly so a later reader does not count 58f4832 as
corroboration.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE

README.md

@@ -29,13 +29,14 @@ real streamer-tools API shape, and pushes decoded frames into
 
 It has **not been run in the OBS GUI on any platform.** macOS builds the real
 module in CI but its artifact is not yet loadable (see the macOS packaging gap
-under CI). Windows CI has **failed on every completed run so far** (7
-consecutive failures on this branch as of this writing); a run against the
-commit with the `-A x64` argument fix is in progress but not yet complete,
-and the commit with the PowerShell rewrite of the Windows steps is still
-queued behind it. Neither fix has a completed, passing run yet. See "Where
-the Windows bootstrap got to" under CI below for the exact record, and check
-current CI status rather than trusting this paragraph's age.
+under CI). Windows CI has **failed on every completed run so far**. The
+`-A x64` argument fix is now confirmed working — the run carrying it got as
+far as building libobs — but it exposed a deeper blocker: OBS 30.0.2's
+opt-in modern CMake path never defines the `OBS::w32-pthreads` target its own
+Windows libobs links against. The PowerShell rewrite of the Windows steps is
+still queued and unproven. See "Where the Windows bootstrap got to" under CI
+below for the trace and the options, and check current CI status rather than
+trusting this paragraph's age.
 
 See "What is verified, and how" below for exactly what has and has not been
 checked, and "Testing this by hand" for what a human still needs to do.
@@ -228,7 +229,7 @@ runners available to this repo under the `CyberCoveLLC` org.
 |---|---|---|---|
 | `linux` | `ubuntu-24.04` | `localhost.localdomain` | **Green.** Builds the real adapter against Ubuntu's libobs-dev 30.0.2, runs all six test suites, uploads `build/package` as an artifact |
 | `macos` | `macos-latest` | `home-mac` (Global) | **Green.** Builds libobs 30.0.2 from source, then the real adapter; 6/6 tests; artifact uploaded. But see the macOS packaging gap below |
-| `windows` | `windows-latest` | `winvm-builder` (org-scoped) | **Failing** — 7/7 completed runs on this branch have failed; see below |
+| `windows` | `windows-latest` | `winvm-builder` (org-scoped) | **Failing** — every completed run on this branch has failed. The latest gets as far as building libobs and stops on an OBS-side `OBS::w32-pthreads` target that its own modern CMake path never defines; see below |
 
 The Linux job is pinned to `ubuntu-24.04` rather than `ubuntu-latest`: this
 instance's two Linux runners answer `ubuntu-latest` with different releases,
@@ -305,17 +306,66 @@ Windows is by far the slowest job — the `lukka/get-cmake` step alone takes
 pushes leaves a queue that takes an hour to drain.
 
 **The honest record: every completed Windows CI run on this branch has
-failed. 7 consecutive failures**, at the 7 branch commits (in order) that had
-a completed Windows run as of this writing -- all of them at commits before
-the `-A x64` fix below was applied. As of this writing, a Windows run against
-the commit with that fix is in progress but has not yet completed, and the
-commit with the PowerShell rewrite is still queued behind it (the runner's
-serial queue means fixed commits can sit behind older, unfixed ones for a
-while). Do not read either fix below as "confirmed" until a Windows run
-actually goes green on a commit that includes it; check current CI status
-rather than trusting this paragraph's age.
+failed.** The first 7 failures were all at commits predating the `-A x64` fix
+below. The 8th, at `edb0c02` — the first commit that actually carries that fix
+— has since completed, and it is the informative one: **the `-A x64` fix
+worked, and Windows failed further along, on something else.** A later run
+(`58f4832`) then failed for an unrelated reason — its Windows steps still used
+`shell: bash`, which on this runner is WSL and cannot run as local system —
+so it never reached cmake at all and tells us nothing about the bootstrap.
+The PowerShell rewrite that fixes that is still queued and remains unproven.
+Do not read any fix below as "confirmed" beyond what is stated; check current
+CI status rather than trusting this paragraph's age.
 
-Two bugs of its own were found and (believed, not yet proven) fixed:
+What `edb0c02` showed: obs-deps and Qt6 downloaded, CEF skipped, the OBS
+sub-configure ran for 53s and correctly reported "Plugin Support" and "User
+Interface" disabled — then failed at generate time:
+
+```
+CMake Error at libobs/cmake/os-windows.cmake:46 (target_link_libraries):
+  Target "libobs" links to:
+    OBS::w32-pthreads
+  but the target was not found.
+```
+
+**That looks like a genuine hole in OBS 30.0.2's opt-in modern CMake path on
+Windows, not something this repo is doing wrong.** Traced at the 30.0.2 tag:
+
+- `libobs/cmake/os-windows.cmake` links `OBS::w32-pthreads`;
+- that target is defined only by `deps/w32-pthreads/CMakeLists.txt`, reached
+  only through `deps/CMakeLists.txt`;
+- `deps/` is added only by the **legacy** branch of the top-level
+  `CMakeLists.txt`. The modern branch — the one `-DOBS_CMAKE_VERSION=3.0.0`
+  selects — adds `libobs`, `libobs-d3d11`, `libobs-winrt`, `libobs-opengl`,
+  `plugins`, `test/test-input` and `UI`, never `deps`;
+- `libobs/CMakeLists.txt` adds only `deps/libcaption` and `deps/uthash`;
+- `plugins/CMakeLists.txt` returns immediately under `ENABLE_PLUGINS=OFF`, and
+  does not add `deps/` even when enabled.
+
+macOS is unaffected because its libobs does not link w32-pthreads. At 30.0.2
+the modern path was the *default* only on macOS
+(`if(CMAKE_HOST_SYSTEM_NAME MATCHES "(Darwin)" OR OBS_CMAKE_VERSION ...)`),
+which is consistent with the Windows side of it being under-exercised
+upstream.
+
+Deliberately **not** "fixed" by bumping the pin: 30.0.2, 30.1.2, 30.2.3,
+31.0.3 and 31.1.1 were all checked, and every one still links
+`OBS::w32-pthreads` from `libobs/cmake/os-windows.cmake` while none of them
+add `deps/w32-pthreads` from `libobs/CMakeLists.txt`. A version bump is
+therefore not obviously the answer and needs checking rather than assuming.
+Options, roughly in order of preference:
+
+1. Work out how obs-plugintemplate's own Windows CI satisfies this target at
+   its 31.1.1 pin — it builds `obs-frontend-api` rather than `libobs`, which
+   may pull in a different subdirectory set. If so, building that target (and
+   accepting the Qt dependency on Windows only) is the smallest change.
+2. Have the bootstrap add `add_subdirectory(deps/w32-pthreads)` to the
+   extracted OBS tree before configuring. Effective, but a patch against a
+   third-party tree that must be carried across pin bumps.
+3. Drop the from-source libobs on Windows and find a prebuilt OBS SDK.
+
+Two bugs of its own were found; the first is now proven fixed by `edb0c02`
+getting past it, the second is still unproven:
 
 1. Upstream passes `-A x64,version=<Windows SDK>` to the OBS sub-configure,
    and with a current CMake that `,version=` suffix reappears verbatim in the
@@ -328,13 +378,28 @@ Two bugs of its own were found and (believed, not yet proven) fixed:
    Unable to download .../windows-deps-2023-11-03-x64,version=10.0.26100.0.zip
    ```
 
-   Plain `-A x64` now.
-2. The Windows CI steps were originally written in bash (via
-   `shell: bash`), which is a poor fit for a `windows-latest` runner's
-   default toolchain expectations; they were rewritten in PowerShell.
+   Plain `-A x64` now. **Confirmed fixed:** the `edb0c02` run got past this
+   and downloaded `windows-deps-2023-11-03-x64.zip` correctly.
+2. The Windows CI steps were originally written in bash (via `shell: bash`)
+   and were rewritten in PowerShell. **The bash version is now proven broken**
+   by the `58f4832` run: on `winvm-builder`, `bash` resolves to WSL, and WSL
+   refuses to run under the service account the runner uses —
 
-Until a Windows run completes green with both fixes in place, Windows should
-be treated as unverified beyond "the core library and the WinHTTP backend
-compile and their tests pass", which earlier (failing-job) runs did show
-before failing later in the job. Expect further iterations there of the same
-kind the macOS bootstrap needed.
+   ```
+   Running WSL as local system is not supported.
+   Error code: Bash/WSL_E_LOCAL_SYSTEM_NOT_SUPPORTED
+   ##[error]Process completed with exit code 1.
+   ```
+
+   so the step died on the shell without ever invoking cmake. The PowerShell
+   rewrite is therefore necessary, but **still unproven in the other
+   direction** — no completed run has yet included it. Note this also means
+   `58f4832`'s failure says nothing about the `w32-pthreads` blocker; that
+   result comes from `edb0c02` alone.
+
+Until a Windows run completes green, Windows should be treated as unverified
+beyond "the core library and the WinHTTP backend compile and their tests
+pass", which earlier (failing-job) runs did show before failing later in the
+job. The `w32-pthreads` blocker above is the next thing to solve, and it is
+upstream's problem to work around rather than a defect in this repo's
+bootstrap.