Merge pull request 'docs: the Windows plugin dir is ProgramData, not the config dir' (#2) from docs/windows-plugin-path into main

README.md

@@ -142,10 +142,19 @@ 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.