docs/release: drop the C1 licensing gate, simplify install instructions

The WebRTC/OpenH264 attribution question tracked as "C1" throughout
README, third_party/livekit/README.md, the release-notes template, and
both workflow header comments is the project owner's call, and it has
been made -- own sign-off given and reaffirmed. Remove the gate
language and the extended research writeup from release-facing docs;
keep the actual LICENSE/NOTICE files themselves (Apache-2.0 requires
shipping those regardless of any of this).

Also simplify the release notes' install instructions per owner
request: point at each platform's default OBS plugins folder rather
than walking through verbose per-platform copy/extract instructions --
the archives already extract straight into place (prior commit), so a
short pointer is all that's needed.

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

README.md

@@ -8,40 +8,15 @@ Media-Source path for directors. Full design:
 
 ## Status
 
-**Release/distribution of built binaries is blocked pending owner sign-off.**
-This plugin statically/dynamically pulls in Google WebRTC and OpenH264 code
-through the LiveKit SDK — a real patent/royalty question (OpenH264/WebRTC)
-that only the project owner can decide. Nothing in this repo should be built
-into a package and handed out, posted, or attached to a public release until
-that sign-off happens. See `third_party/livekit/README.md` for the specifics
-of what is and is not currently known/shipped on the licensing side —
-including a 2026-09-07 finding, sourced from Cisco's own OpenH264 FAQ, that
-the way LiveKit's WebRTC build normally links OpenH264 (statically, from
-source, not Cisco's runtime-downloaded binary) is specifically the case Cisco
-says voids their MPEG-LA royalty coverage and shifts it to the redistributor.
-That finding has not been confirmed against LiveKit's actual pinned build —
-see the third_party doc for exactly what is and isn't verified. (CI in
-`.gitea/workflows/build.yml` only builds, tests, and uploads CI-internal
-build artifacts — it does not create a Gitea Release or otherwise publish
-anything publicly.
+This project's own code is Apache-2.0 (relicensed from GPL-2.0-or-later to
+match the vendored LiveKit binaries, which are also Apache-2.0 — see
+`LICENSE` and `NOTICE`, and `third_party/livekit/` for LiveKit's own).
 
-`.gitea/workflows/release.yml` is the mechanism that *would* publish a
-release, but it does not run automatically: it is gated on someone pushing a
-`v*` tag, which is the actual sign-off gate in practice — don't push one
-until the owner has actually signed off on C1. When it does run, it packages
-each platform's `build/package/` (or macOS's bundle output, once that lands)
-into a zip and creates a **draft** Gitea Release, whose generated release
-notes lead with the same C1 reminder as this section, so whoever opens the
-draft to publish it sees the open question again before doing so. Building
-that mechanism is not the same as clearing C1 — it still requires the same
-owner sign-off before a tag gets pushed.)
-
-The separate license-compatibility question — this repository's own top-level
-`LICENSE` was GPLv2 while the vendored LiveKit binaries are Apache-2.0, which
-are incompatible — is **resolved**: the project owner has relicensed this
-project's own first-party code to Apache-2.0, matching LiveKit. Everything in
-this repo is now Apache-2.0, so there is no remaining GPL/Apache
-incompatibility.
+`.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.
 
 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