docs: record the first confirmed OBS GUI load (Windows)

The v0.1.0 Windows artifact loaded into OBS 32.2.2 on Windows 11 (build
26200) on a director's machine on 2026-09-09, from
C:\ProgramData\obs-studio\plugins\streamer-tools-camera\bin\64bit\. That
retires "has not been run in the OBS GUI on any platform", which this README
asserted in four places.

Scoped deliberately to what was actually observed: the module loads and
registers its source type. Whether video renders, the colours, A/V sync,
latency, and mid-show publisher restart are all still unverified, and Linux
and macOS have still never been opened in the GUI. The "Not verified
anywhere" list now says so explicitly rather than being deleted.

Also drops the release-draft rationale that pointed at the no-GUI-load state,
and carries the ProgramData install-path warning up into the status section,
since that is what stopped the first GUI load from happening sooner.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AzGnvQ6wfD7bw7PZN35ft9

README.md

@@ -14,18 +14,30 @@ match the vendored LiveKit binaries, which are also Apache-2.0 — see
 
 `.gitea/workflows/build.yml` builds, tests, and uploads CI-internal build
 artifacts on every push. `.gitea/workflows/release.yml` packages a tagged
-build (`v*`) into a **draft** Gitea Release — draft because nobody has run
-this in the OBS GUI yet (see below), not because of anything else; a human
-still needs to open it and click Publish.
+build (`v*`) into a **draft** Gitea Release; a human still needs to open it
+and click Publish.
 
 The plugin is **functionally complete on Linux and verified end to end there**
 (module loads into real libobs, connects to a real LiveKit server through the
 real streamer-tools API shape, and pushes decoded frames into
 `obs_source_output_video`/`_audio`).
 
-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).
+**First confirmed OBS GUI load: Windows, 2026-09-09** — the v0.1.0 release
+artifact loaded into OBS 32.2.2 on Windows 11 (build 26200) on a director's
+machine, from
+`C:\ProgramData\obs-studio\plugins\streamer-tools-camera\bin\64bit\`.
+That retires "the module will not even load in a real OBS" for Windows. It
+does **not** yet cover whether video renders correctly, colours, A/V sync or
+latency — see "Not verified anywhere" below for what is still open. Linux and
+macOS have still never been opened in the GUI; macOS builds the real module in
+CI but its artifact is not yet loadable (see the macOS packaging gap under CI).
+
+⚠️ **The install directory is not the same on every platform, and getting it
+wrong fails silently.** On Windows it is
+`C:\ProgramData\obs-studio\plugins\` (`GetProgramDataPath` →
+`CSIDL_COMMON_APPDATA`), **not** `%APPDATA%\obs-studio\` — see the packaging
+section. That mistake cost the director above an evening: OBS logs nothing at
+all for a plugin it never finds.
 
 **Windows CI is now green.** The run at `f27b1c0` is the first completed
 green Windows job on this repository: the from-source libobs bootstrap
@@ -35,8 +47,8 @@ suites pass, and `build\package\bin\64bit\streamer-tools-camera.dll`
 out of the job's own log body, not inferred from the job status. That also
 retires three previously-unproven items in one go: the `-A x64` argument fix,
 the PowerShell rewrite of the Windows steps, and the `add_subdirectory`
-patch for `OBS::w32-pthreads`. Windows is still **unverified in the OBS GUI**,
-exactly like the other two platforms. See "Where the Windows bootstrap got
+patch for `OBS::w32-pthreads`. Windows has since been **loaded in the real OBS
+GUI** (see above); Linux and macOS have not. See "Where the Windows bootstrap got
 to" under CI below for the whole trace, and check current CI status rather
 than trusting this paragraph's age.
 
@@ -142,17 +154,28 @@ build/package/licenses/...
 ```
 
 That is exactly the layout OBS searches on Linux and Windows —
-`<config>/obs-studio/plugins/<name>/bin/64bit` plus a sibling `data/`, per
-`AddExtraModulePaths()` in obs-studio's `UI/window-basic-main.cpp` — so
-`build/package/` is a straight drop-in. The module resolves the LiveKit
-libraries from `$ORIGIN` (verified: `ldd` on the staged copy resolves both
+`<base>/obs-studio/plugins/<name>/bin/64bit` plus a sibling `data/`, per
+`AddExtraModulePaths()` in obs-studio (`UI/window-basic-main.cpp` in 30.x,
+`frontend/widgets/OBSBasic.cpp` in 32.x) — so `build/package/` is a straight
+drop-in. **`<base>` is NOT the same directory on every platform**, and getting
+this wrong is silent: OBS logs nothing at all for a plugin it never finds.
+Linux uses the user config dir (`GetAppConfigPath` → `~/.config`), but Windows
+uses `GetProgramDataPath` (`CSIDL_COMMON_APPDATA`) — i.e.
+`C:\ProgramData\obs-studio\plugins\`, **not** `%APPDATA%\obs-studio\`
+(`CSIDL_APPDATA`), which on Windows holds OBS's config and is never scanned for
+plugins. This bit a director on 2026-09-09: a correctly-shaped install under
+`AppData\Roaming` produced a log with zero mention of the module.
+
+The module resolves the LiveKit libraries from `$ORIGIN` (verified: `ldd` on the staged copy resolves both
 to `bin/64bit/`), not from the build tree. macOS is not this shape; see the
 macOS packaging gap under CI.
 
 ## Testing this by hand
 
-**Nobody has yet run this in the OBS GUI. That test is still outstanding on
-all three platforms.** To do it on Linux:
+**The module has been loaded in the OBS GUI on Windows once (2026-09-09, OBS
+32.2.2 / Windows 11 26200) — nothing beyond "it loads and registers its source"
+is confirmed there, and Linux and macOS have never been opened in the GUI at
+all.** To do it on Linux:
 
 ```
 mkdir -p ~/.config/obs-studio/plugins/streamer-tools-camera
@@ -208,7 +231,11 @@ livekit-server 1.13.6 in dev mode):
 | Two sources in one OBS process | same harness with a second source added: both connect with distinct nonce identities, both receive frames, both tear down cleanly |
 
 **Not verified anywhere:**
-- The OBS GUI, on any platform. No human has looked at this in OBS.
+- Anything past module load in the OBS GUI. Windows 2026-09-09 confirms the
+  module loads and its source type appears; whether video actually renders
+  (right way up, right colours), what the A/V sync and latency look like, and
+  whether a publisher restarting mid-show recovers on screen are all still
+  unanswered. Linux and macOS have not been opened in the GUI at all.
 - macOS beyond "CI builds and links the real module and the core tests pass".
   Its artifact is a bare `.so` with a relative libobs install name and will
   not load in OBS.app — see the macOS packaging gap under CI.