ci: add tag-triggered release packaging workflow

Adds .gitea/workflows/release.yml, triggered only on a pushed v* tag, which
builds all three platforms (reusing the exact same configure/build/test
commands as build.yml, now factored out into .gitea/scripts/ so the two
workflows can't drift), zips each platform's build/package/ output, and
creates a draft Gitea Release with the archives attached.

This is packaging automation only -- it does not resolve or bypass the C1
WebRTC/OpenH264 release gate documented in README.md's Status section.
Nothing publishes until a human deliberately pushes a version tag (which
should not happen before owner sign-off) and then explicitly publishes the
resulting draft. The generated release notes lead with a restatement of the
open C1 question specifically so that second step can't be taken by
accident.

build.yml is refactored (not rewritten) to call the same shared scripts;
its job/step behavior is otherwise unchanged.

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

README.md

@@ -15,10 +15,20 @@ 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. (CI in
-`.gitea/workflows/build.yml` currently only builds, tests, and uploads
-CI-internal build artifacts — it does not create a Gitea Release or otherwise
-publish anything publicly; if that ever changes, the new step must carry this
-same gate.)
+`.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.
+
+`.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
@@ -68,7 +78,9 @@ obs-adapter/             - thin OBS glue (C++)
   data/locale/en-US.ini
 scripts/livekit-dev-room.py - mints tokens for the integration test
 third_party/livekit/     - redistribution notices for the LiveKit binaries
-.gitea/workflows/build.yml  - 3-platform CI matrix
+.gitea/scripts/          - the actual per-platform build commands, shared by build.yml and release.yml
+.gitea/workflows/build.yml    - 3-platform CI matrix (every push/PR; never publishes)
+.gitea/workflows/release.yml  - packages + creates a draft Gitea Release (only on a `v*` tag push; see Status above)
 ```
 
 ## How it works