Fix Windows configure: point find_package at OBS's exported w32-pthreads

The libobs_DIR fix in 79de5e8f worked -- libobsConfig.cmake now loads on the
Windows runner -- and immediately exposed the next link in the same chain.
obs-studio's libobsConfig.cmake.in carries, under if(MSVC), a hard

    find_dependency(w32-pthreads REQUIRED)

because libobs/cmake/os-windows.cmake links PUBLIC OBS::w32-pthreads. That
lookup failed and aborted the whole configure.

The cause is not a missing export, which was the first hypothesis:
deps/w32-pthreads/CMakeLists.txt ends in target_export(w32-pthreads), the
same helper libobs itself uses, so the install(TARGETS ... EXPORT),
install(EXPORT ... NAMESPACE OBS::) and generated w32-pthreadsConfig.cmake
all exist and all run -- CMake would have hard-errored at generate time if
w32-pthreads were in no export set, and our own patch adds it under the
libobs subtree, which installs before the tolerated obs-frontend-api install
error stops the rest.

It is the same search-path mismatch libobs itself had: target_export installs
to <prefix>/${OBS_CMAKE_DESTINATION}/<target>/, which on Windows is
<prefix>/cmake/w32-pthreads/ -- a shape find_package's Config-mode suffixes
never search. So apply the same remedy CMake's own error message suggests,
and apply it before the find_package(libobs) call that transitively triggers
the find_dependency.

Also adds a fallback Findw32-pthreads.cmake, reached only when that export is
genuinely absent, which reconstructs OBS::w32-pthreads from the bootstrap's
artifacts, and a repair for a locationless imported target mirroring the
existing OBS::libobs one. The fallback deliberately lives in
cmake/windows/find-fallback/ rather than cmake/windows/, which osconfig.cmake
already puts on CMAKE_MODULE_PATH: a find module there would shadow OBS's
real exported package on every build, since MODULE mode is tried first.

Verified on Linux (this is a Linux sandbox) by reconstructing the exact
failure -- a stub libobsConfig.cmake with the same find_dependency, reached
through libobs_DIR -- and confirming it fails without this block and passes
with it, and separately that deleting the package routes find_package through
the fallback module instead. A full Linux configure of the repo is unchanged;
both new blocks are inside if(OS_WINDOWS) and the upstream find_dependency is
inside if(MSVC), so macOS and Linux are no-ops.

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

README.md

@@ -458,3 +458,86 @@ 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.
+
+### After the w32-pthreads target: the w32-pthreads *package*
+
+The `add_subdirectory(deps/w32-pthreads)` patch above did its job — the
+`edb0c02`-era generate error is gone, obs-studio 30.0.2 configures, builds
+`w32-pthreads.dll` and `obs.dll`, and installs. Two further Windows-only
+blockers then surfaced behind it, both the same underlying upstream mismatch
+and neither one a defect in this repo:
+
+1. **`find_package(libobs)` could not locate the package it had just
+   installed.** obs-studio's `cmake/windows/defaults.cmake` sets
+   `OBS_CMAKE_DESTINATION=cmake`, and `target_export()` installs each
+   package to `<prefix>/${OBS_CMAKE_DESTINATION}/<target>/` — i.e.
+   `.deps/cmake/libobs/`. That is not one of CMake's Config-mode search
+   suffixes (`<prefix>/cmake/` is, but only for a config file sitting
+   *directly* in it; `<prefix>/<name>*/cmake/` is, but the `<name>`
+   directory has to come first). Fixed in `79de5e8f` by setting
+   `libobs_DIR` explicitly; the long comment above that block in
+   `CMakeLists.txt` has the full reasoning.
+
+2. **…and then `libobsConfig.cmake` could not locate `w32-pthreads` for
+   exactly the same reason.** `libobs/cmake/os-windows.cmake` links
+   `PUBLIC OBS::w32-pthreads`, so upstream's `libobsConfig.cmake.in` carries
+   a hard `find_dependency(w32-pthreads REQUIRED)` under `if(MSVC)`. Once
+   fix 1 finally got that config file loaded, the dependency lookup inside
+   it failed and killed the configure:
+
+   ```
+   By not providing "Findw32-pthreads.cmake" in CMAKE_MODULE_PATH this project
+   has asked CMake to find a package configuration file provided by
+   "w32-pthreads", but CMake did not find one.
+     .deps/cmake/libobs/libobsConfig.cmake:30 (find_dependency)
+   ```
+
+   **This is not a missing export**, which was the first hypothesis and is
+   worth recording as wrong: `deps/w32-pthreads/CMakeLists.txt` ends with
+   `target_export(w32-pthreads)`, the same helper `libobs` itself uses, so
+   it does emit `install(TARGETS … EXPORT w32-pthreadsTargets)`,
+   `install(EXPORT … NAMESPACE OBS::)` and a generated
+   `w32-pthreadsConfig.cmake`, all `COMPONENT Development`. Two independent
+   arguments say those rules ran: CMake hard-errors at generate time if an
+   exported target links a target that is in no export set at all (and OBS's
+   generate step succeeded), and this repo's patch adds `deps/w32-pthreads`
+   from `libobs/CMakeLists.txt`, making it part of the `libobs` subtree —
+   which installs *before* the tolerated `UI/obs-frontend-api` install error
+   aborts the rest. The package really is at `.deps/cmake/w32-pthreads/`;
+   `find_package` was simply never going to look there.
+
+   So the fix is the same one-liner as for `libobs`, and it is literally
+   what CMake's own error message suggests: set `w32-pthreads_DIR` before
+   the `find_package(libobs)` call that transitively triggers the
+   `find_dependency`. Both `_DIR` blocks now sit next to each other in
+   `CMakeLists.txt`.
+
+   Behind that sits `cmake/windows/find-fallback/Findw32-pthreads.cmake`,
+   used only if that export is genuinely absent from `.deps/`. It rebuilds
+   `OBS::w32-pthreads` by hand from the bootstrap's own artifacts. It
+   deliberately does *not* live in `cmake/windows/`, which
+   `cmake/common/osconfig.cmake` already puts on `CMAKE_MODULE_PATH` for
+   every Windows configure — a find module there would shadow OBS's real
+   exported package on every build, since `find_package` tries MODULE mode
+   before CONFIG mode. `CMakeLists.txt` appends the `find-fallback/`
+   directory to `CMAKE_MODULE_PATH` only after it has established the real
+   export is missing, and logs what *is* under `.deps/cmake/` when it does,
+   so a future failure of this shape is answered by the CI log rather than
+   by another run.
+
+   Note this package is load-bearing for more than the dependency check:
+   `libobs/util/threading.h` does `#include <pthread.h>`, and on Windows
+   that header only exists because `target_export(w32-pthreads)` installs
+   `pthread.h`/`sched.h` as `PUBLIC_HEADER` into `.deps/include/`.
+
+Verified before pushing, on Linux, since this is a Linux sandbox: a
+reconstruction of the exact failure — a stub `libobsConfig.cmake` containing
+`find_dependency(w32-pthreads REQUIRED)`, reached through `libobs_DIR`, with
+the package installed at `.deps/cmake/w32-pthreads/` — reproduces the CI
+error without the `w32-pthreads_DIR` block and passes with it; and the
+fallback find module was exercised separately by deleting that package, with
+`find_package` resolving through MODULE mode to it instead. A full Linux
+configure of this repo is unchanged (both blocks are inside `if(OS_WINDOWS)`,
+and the upstream `find_dependency` is inside `if(MSVC)`, so macOS and Linux
+are pure no-ops). Whether the real Windows runner now gets to a
+`streamer-tools-camera.dll` is what the CI run on this commit has to show.