docs: the -A x64 fix is confirmed; Windows now blocked on OBS's own CMake

Updates the Windows record written in 551f782, which was accurate when
written but has since been overtaken: the run it described as "in progress"
(edb0c02, the first commit carrying the -A x64 fix) has now completed.

The informative part is that the fix worked and Windows failed further along.
obs-deps and Qt6 downloaded, CEF was 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.

Traced at the 30.0.2 tag, and it does not appear to be anything this repo is
doing wrong:

  - libobs/cmake/os-windows.cmake links OBS::w32-pthreads;
  - that target exists only in deps/w32-pthreads/CMakeLists.txt, reached only
    via deps/CMakeLists.txt;
  - deps/ is added only by the LEGACY branch of the top-level CMakeLists. The
    modern branch that -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, and at
30.0.2 the modern path was the default only on macOS -- consistent with the
Windows side of it being under-exercised upstream.

Deliberately NOT "fixed" here by bumping the pin: 30.0.2, 30.1.2, 30.2.3,
31.0.3 and 31.1.1 all still link OBS::w32-pthreads and none of them add
deps/w32-pthreads from libobs/CMakeLists.txt, so a bump is not obviously the
answer and needs checking rather than assuming. Three options are written up
with the evidence behind each, so whoever picks this up starts from a
diagnosis instead of from the error message.

Everything else 551f782 said stands, including its caution not to treat
either fix as confirmed without a green run -- the PowerShell rewrite is
still queued and still unproven, and is marked as such. The CI table row and
the top-level Status paragraph are updated to match; the licensing/release
gate is untouched.

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
+under CI). Windows CI has **failed on every completed run so far**. The
-consecutive failures on this branch as of this writing); a run against the
+`-A x64` argument fix is now confirmed working — the run carrying it got as
-commit with the `-A x64` argument fix is in progress but not yet complete,
+far as building libobs — but it exposed a deeper blocker: OBS 30.0.2's
-and the commit with the PowerShell rewrite of the Windows steps is still
+opt-in modern CMake path never defines the `OBS::w32-pthreads` target its own
-queued behind it. Neither fix has a completed, passing run yet. See "Where
+Windows libobs links against. The PowerShell rewrite of the Windows steps is
-the Windows bootstrap got to" under CI below for the exact record, and check
+still queued and unproven. See "Where the Windows bootstrap got to" under CI
-current CI status rather than trusting this paragraph's age.
+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,63 @@ 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
+failed.** The first 7 failures were all at commits predating the `-A x64` fix
-a completed Windows run as of this writing -- all of them at commits before
+below. The 8th, at `edb0c02` — the first commit that actually carries that fix
-the `-A x64` fix below was applied. As of this writing, a Windows run against
+— has since completed, and it is the informative one: **the `-A x64` fix
-the commit with that fix is in progress but has not yet completed, and the
+worked, and Windows failed further along, on something else.** The PowerShell
-commit with the PowerShell rewrite is still queued behind it (the runner's
+rewrite is still queued behind it and remains unproven. Do not read either fix
-serial queue means fixed commits can sit behind older, unfixed ones for a
+below as "confirmed"; check current CI status rather than trusting this
-while). Do not read either fix below as "confirmed" until a Windows run
+paragraph's age.
-actually goes green on a commit that includes it; 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 +375,16 @@ 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.
+   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`), which is a poor fit for a `windows-latest` runner's
-   default toolchain expectations; they were rewritten in PowerShell.
+   default toolchain expectations; they were rewritten in PowerShell. **Still
+   unproven** — no completed run has included it.
 
-Until a Windows run completes green with both fixes in place, Windows should
+Until a Windows run completes green, Windows should be treated as unverified
-be treated as unverified beyond "the core library and the WinHTTP backend
+beyond "the core library and the WinHTTP backend compile and their tests
-compile and their tests pass", which earlier (failing-job) runs did show
+pass", which earlier (failing-job) runs did show before failing later in the
-before failing later in the job. Expect further iterations there of the same
+job. The `w32-pthreads` blocker above is the next thing to solve, and it is
-kind the macOS bootstrap needed.
+upstream's problem to work around rather than a defect in this repo's
+bootstrap.