Document release distribution as single public repo, not split

The public/private repo split got reverted (see previous commit) in
favor of just making this repo public directly. PLAN.md's Release
distribution section still described the old "later, once stable"
placeholder from before either version was built -- update it to match
what's actually running.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

PLAN.md

@@ -149,13 +149,38 @@ Two different loops -- do not conflate them:
    briefly interrupts the live, shared Jellyfin instance -- **do not do this
    routinely; only for actual multi-friend sync test sessions, and confirm
    with the user first.**
-3. **Release distribution (later, once stable):** package as a versioned zip
+3. **Release distribution -- DONE (Phase 5, built 2026-07-09).** Package as a
-   + `meta.json`, host a plugin-repository manifest via Gitea (raw file URLs
+   versioned zip + `manifest.json`, host via Gitea, add the repo URL in
-   or release attachments both work, Jellyfin just needs HTTP(S) access to
+   Jellyfin's dashboard. Mirrors MR-Discord's tag -> Gitea Actions -> build
-   the manifest + zip), add the repo URL in Jellyfin's dashboard. Mirrors
+   pipeline, just producing a plugin zip instead of a Docker image.
-   MR-Discord's tag -> Gitea Actions -> build pipeline, just producing a
+   - **Repo (`JellyfinSyncPlus`) itself is public** -- briefly tried a
-   plugin zip instead of a Docker image. Slow iteration loop -- not for
+     separate private-source/public-distribution repo split (Gitea has no
-   development, only for shipping tested versions.
+     way to make individual release assets public on a private repo; repo
+     visibility is all-or-nothing there), but decided to just make this repo
+     public instead rather than maintain two repos. Manifest + releases live
+     directly on this repo.
+   - `dev/package-release.sh` -- builds Release config, zips the DLL,
+     computes its MD5 checksum, updates `manifest.json` (schema-verified
+     against a real published Jellyfin plugin repo's actual file). Live-
+     tested locally.
+   - `dev/update_manifest.py` -- the manifest merge logic package-release.sh
+     calls; reads plugin metadata/changelog from `build.yaml`.
+   - `.github/workflows/release.yml` -- on a `v*` tag push: builds
+     (including pulling the two private SDK assemblies straight from the
+     pinned `linuxserver/jellyfin:10.11.6` image via `docker cp`, mirroring
+     `dev/extract-private-refs.sh` for CI), packages, creates a Gitea
+     release with the zip attached, commits the updated `manifest.json`
+     back to `master`.
+   - `.github/workflows/build.yml` -- plain build-check on every push/PR to
+     `master`, mirroring MR-Discord's `build.yml` pattern.
+   - **Live-verified 2026-07-09**: tagged and pushed `v0.2.0.0` -- confirmed
+     the workflow ran, created a real Gitea release with the zip attached,
+     and committed a real `manifest.json` back to `master`. Manifest URL:
+     `https://gitea.mrcynic.site/seer/JellyfinSyncPlus/raw/branch/master/manifest.json`.
+   - Once installed, Jellyfin has no hot-reload -- same as local dev, a
+     server restart is required. On the real k8s deployment that's the
+     "confirm with the user first" milestone action from the "Dev / test /
+     iterate workflow" section above, not a routine step.
 
 ## Known friction / risks (flagged going in, not discovered later)