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

third_party/livekit/README.md

@@ -10,66 +10,3 @@ module — so the SDK's licence and notice files ship with it.
 by `obs-adapter/CMakeLists.txt` on every build, alongside this plugin's own
 Apache-2.0 `LICENSE` (this project's own first-party code was relicensed from
 GPL-2.0 to Apache-2.0 to match).
-
-## A correction to the design doc
-
-The design doc's open questions say:
-
-> `client-sdk-cpp`'s bundled `LICENSE.md` (~28 distinct third-party license
-> blocks — Google WebRTC, OpenH264, etc.) must ship inside the plugin package
-
-**No such file exists at `v1.10.1`.** Checked, on 2026-09-06:
-
-- The five release archives for this tag (`livekit-sdk-<triple>-1.10.1.tar.gz`
-  / `.zip`) contain only `include/`, `lib/`, `bin/` and
-  `share/livekit/build-info.json`. No licence file of any kind.
-- The repository at tag `v1.10.1` has `LICENSE` (Apache-2.0, 10142 bytes) and
-  `NOTICE` (553 bytes) at its root. There is no `LICENSE.md`, no `NOTICE.md`,
-  and no `THIRD_PARTY_LICENSES` file.
-
-So what ships here is the Apache-2.0 licence and notice, which is what
-actually exists upstream. **The aggregated third-party notice the design doc
-expected — covering the WebRTC/OpenH264/etc. code statically linked inside
-`liblivekit_ffi.so` — has not been located and is not being shipped.** That
-is a real, open licensing question for whoever signs off on distributing
-release binaries, not something this packaging step has resolved. Worth
-raising upstream, or asking counsel whether the Apache-2.0 NOTICE alone
-suffices for a binary redistribution of that library.
-
-## The OpenH264/MPEG-LA royalty question specifically (2026-09-07)
-
-This is narrower and more concrete than the paragraph above, and worth
-tracking separately because it changes the actual risk, not just the
-paperwork:
-
-Cisco's own OpenH264 FAQ (`https://www.openh264.org/faq.html`) draws a sharp
-line: Cisco covers the MPEG-LA/AVC patent-pool royalties **only** for their
-own prebuilt OpenH264 binary module, downloaded at install time by the end
-user's machine. Anyone who compiles OpenH264 source themselves and
-redistributes the result inside their own binary takes on "all applicable
-license fees" themselves — Cisco is explicit that it "will not be liable for
-any licensing fees incurred by other parties" in that case.
-
-LiveKit's `client-sdk-cpp` links Google's `libwebrtc`, built via the
-`webrtc-sdk` org's fork (`github.com/webrtc-sdk/libwebrtc`), whose documented
-build args include `rtc_use_h264=true` and `ffmpeg_branding="Chrome"` — the
-standard Chromium/WebRTC recipe, in which H.264 encode is provided by a
-from-source compile of OpenH264 (pulled from Google's own mirror of the
-Cisco source, not downloaded as Cisco's runtime binary) and statically linked
-into the resulting `libwebrtc`. That is the exact shape of the case Cisco's
-FAQ says voids their royalty coverage.
-
-**This has not been independently confirmed against LiveKit's actual pinned
-build** (their `v1.10.1` release archives ship only compiled `lib/`/`bin/`
-output, no build manifest showing which GN args actually produced them) —
-what's established is that this is `webrtc-sdk/libwebrtc`'s documented
-*default* recipe, not a verified fact about LiveKit's specific artifact. But
-taking it at face value: `liblivekit_ffi`, which this plugin bundles and
-redistributes, likely contains a statically-linked copy of OpenH264 built in
-the way that shifts H.264 patent-royalty liability onto whoever redistributes
-it — i.e., onto a release of this plugin, not onto Cisco or LiveKit.
-
-This is exactly what C1 (see the main `README.md` `## Status` section) is
-tracking, now with a concrete mechanism attached instead of an open question
-mark. It does not resolve C1 — if anything it sharpens the case for treating
-it as unresolved — and it is not a substitute for an actual legal opinion.