Fix Windows find_package(libobs) and make CI hard-fail when the OBS module is missing

Root cause of the find_package(libobs) failure on Windows: OBS's own
modern-CMake Windows layout (obs-studio/cmake/windows/defaults.cmake sets
OBS_CMAKE_DESTINATION=cmake) installs libobs's CMake package config to
<prefix>/cmake/libobs/ -- a shape find_package(libobs CONFIG) never
searches under CMAKE_PREFIX_PATH. Verified empirically with
--debug-find-pkg=libobs: CMake's Config-mode search suffixes try
<prefix>/cmake/libobsConfig.cmake (no <name> subdirectory) and
<prefix>/libobs*/cmake/... (a <name>-prefixed dir first), never
<prefix>/cmake/<name>*/. This has nothing to do with the earlier "file
INSTALL cannot find obs-frontend-api.dll" error the bootstrap already
tolerates -- libobs is the first subdirectory obs-studio's modern
top-level CMakeLists.txt adds (well before UI), so libobs's own
install(EXPORT ...) rules already completed by the time that later,
unrelated install error aborts the script. macOS is unaffected
(OBS_CMAKE_DESTINATION=lib/cmake there, matching the standard
<prefix>/lib*/cmake/<name>*/ suffix), and so is Linux's libobs-dev
(/usr/lib/<arch>/cmake/libobs/, same standard suffix).

Fix: point libobs_DIR directly at the from-source Windows install when it
exists, bypassing find_package's path-search heuristics entirely. Also
fixed a secondary bug found while tracing this: the existing WIN32
locationless-OBS::libobs repair looked for obs.dll under
"<deps>/bin" instead of the actual OBS_EXECUTABLE_DESTINATION,
"<deps>/bin/64bit".

Also make the Windows and macOS "Show what was built" CI steps hard-fail
when the OBS adapter module is missing, instead of only printing a
message. Several recent "green" Windows runs silently shipped a
core-library-only build because of the bug above; nothing in CI caught
it, only a human reading the raw log by hand. Left Linux untouched (its
check is already a hard, non-"|| true" verification). Applied the same
hard-fail treatment to macOS: its bootstrap has been reliably building
the real module in CI (6/6 tests, per README), so there's no longer a
known legitimate reason for a silent core-only fallback there either --
the documented macOS packaging/bundle-loadability gap is a separate,
already-visible issue this check doesn't touch.

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

.gitea/workflows/build.yml

@@ -100,10 +100,25 @@ jobs:
         run: ctest --test-dir build --output-on-failure
 
       - name: Show what was built
+        # This used to be informational only (every command "|| true"'d), so
+        # a bootstrap failure that silently fell back to a core-library-only
+        # build still reported a green job -- exactly the false-positive
+        # class of bug this step exists to catch, caught instead by a human
+        # reading the raw log by hand. The macOS bootstrap has been reliably
+        # building the real module in CI (6/6 tests, artifact uploaded --
+        # see README), so a missing module here is a regression to fail
+        # loudly on, not the old silent fallback. (This is separate from the
+        # macOS packaging gap in README -- that the module doesn't yet load
+        # as an OBS.app bundle -- which this check does not and cannot test.)
         run: |
           ls -la .deps/Frameworks/libobs.framework/Resources/cmake || true
-          ls -la build/package/bin || true
-          otool -L build/package/bin/streamer-tools-camera.so || true
+          if [ ! -f build/package/bin/streamer-tools-camera.so ]; then
+            echo "::error::no plugin module was built -- build/package/bin/streamer-tools-camera.so is missing. The macOS from-source libobs bootstrap is expected to succeed; treat this as a build failure, not a core-library-only fallback."
+            exit 1
+          fi
+          ls -la build/package/bin
+          otool -L build/package/bin/streamer-tools-camera.so
+          otool -L build/package/bin/streamer-tools-camera.so | grep -E 'obs|livekit'
 
       - name: Upload plugin
         continue-on-error: true
@@ -150,11 +165,25 @@ jobs:
         run: ctest --test-dir build -C Release --output-on-failure
 
       - name: Show what was built
+        # This used to be informational only: the else branch printed a
+        # message and exited 0, so a bootstrap failure that silently fell
+        # back to a core-library-only build (or a find_package(libobs)
+        # failure after a libobs that genuinely built, per the
+        # find_package(libobs) CMakeLists.txt fix above) still reported a
+        # green job -- exactly the false-positive class of bug this step
+        # exists to catch, caught instead by a human reading the raw log by
+        # hand across several "green" runs. The from-source libobs bootstrap
+        # is now expected to work reliably on this runner (that is the whole
+        # point of the buildspec bootstrap + find_package fix), so a missing
+        # module here is a regression to fail loudly on, not the old silent
+        # fallback.
         run: |
-          if (Test-Path build\package\bin\64bit) {
+          $module = "build\package\bin\64bit\streamer-tools-camera.dll"
+          if (Test-Path $module) {
             Get-ChildItem build\package\bin\64bit
           } else {
-            Write-Host "no plugin module was built (core library only)"
+            Write-Host "::error::no plugin module was built -- $module is missing. The Windows from-source libobs bootstrap is expected to succeed; treat this as a build failure, not a core-library-only fallback."
+            exit 1
           }
 
       - name: Upload plugin