docs: describe the shipped bakery product and single-trunk releases

README still called the GTK picker and mirroring pipeline stubs. Both
are built: breadcastd discovers Cast and DLNA devices and owns the
session; breadcast is the GTK picker. Install is bakery; this is not
on the BOS ISO.

CONTRIBUTING now follows the ecosystem single-trunk main + RC-tag
model. Leftover dev/beta CI workflows are documented, not rewritten.
bread-theme and bread-utils already pin bread-ecosystem v0.7.1.

CONTRIBUTING.md

@@ -1,23 +1,18 @@
 # Contributing
 
-`breadcast` — cast your screen to any Chromecast/Google TV, for Hyprland
+`breadcast` — cast your screen to a Chromecast/Google TV or DLNA renderer
 (daemon + GTK4 popup).
 
-Part of the bread ecosystem; this repo follows the same branch/release
-workflow as every other ecosystem product.
+A bakery product in the bread ecosystem — **not** shipped on the BOS ISO
+and not part of the default desktop. This repo follows the same
+branch/release workflow as every other ecosystem product.
 
 ## Branches
 
-- **`main`** — release branch, always tag-ready. Nothing is committed to it
-  directly; it only moves forward via a `beta` merge (see below).
-- **`dev`** — integration branch. All day-to-day work lands here first.
-  Every push to `dev` automatically builds and publishes a **dev-track**
-  build (see Tracks below) — use this to test your change in a real install
-  before it goes any further.
-- **`beta`** — a frozen stabilization branch, cut from `dev` periodically.
-  Every push to `beta` automatically builds and publishes a **beta-track**
-  build. While a freeze is active, only fixes for issues found *in that
-  freeze* should land on `beta`.
+There is one long-lived branch: **`main`**. All day-to-day work lands here.
+Every push to `main` is supposed to publish a **dev-track** build (see
+Tracks below) — a real install you can test before cutting anything more
+formal.
 
 New work — features and bug fixes alike — goes on a short-lived branch:
 
@@ -26,28 +21,29 @@ feature/<short-name>
 fix/<issue-number-or-short-name>
 ```
 
-Branch off `dev`, open a PR/push back into `dev` when ready. If you're fixing
-something reported against an active `beta` freeze, branch off `beta`
-instead, merge the fix there to unblock testers, and also forward the same
-fix into `dev` so it doesn't quietly reappear next cycle.
+Branch off `main`, open a PR/push back into `main` when ready. Short-lived
+branches get deleted on merge — they never accumulate the kind of drift a
+second long-lived branch does.
 
 ## The release cycle
 
-1. Work accumulates on `dev` via `feature/x` / `fix/x` branches. Each push
-   auto-publishes a dev build — install it with `bakery track set dev` and
-   `bakery update --all`, then report or fix anything broken with another
-   push to `dev`.
-2. Once `dev` has gone roughly **a week** without new issues, `beta` is cut
-   fresh from `dev`'s current tip. This freezes it as the stabilization
-   target — `dev` keeps moving independently starting the next cycle.
-3. `beta` is open for anyone to test: `bakery track set beta` and
-   `bakery update --all`. **File issues against anything you find on this
-   repo's Forgejo issue tracker.** Fixes land via `fix/<issue>` branches
-   merged into `beta`.
-4. Once `beta` has gone roughly **a month** without new issues, it's merged
-   into `main` and tagged `vX.Y.Z` — that tag is what actually triggers the
-   stable release build. `beta` is then reset from `dev` to start the next
-   cycle.
+There's no separate `beta` or release branch — "stable" and "beta" are both
+just **tags** on `main`, not branches that need to be kept in sync:
+
+1. Work accumulates on `main` via `feature/x` / `fix/x` branches. Each push
+   is meant to auto-publish a dev build — install it with
+   `bakery track set dev` and `bakery update --all`, then fix anything
+   broken with another push.
+2. When you want to stabilize before a real release, tag a release
+   candidate: `git tag vX.Y.Z-rc.1 && git push origin vX.Y.Z-rc.1` (push to
+   both remotes). That tag alone should trigger a beta-track build —
+   "freezing" is just pausing pushes to `main` while you test it, not a
+   branch operation. Cut `-rc.2`, `-rc.3`, etc. for further fixes.
+3. Once an RC has gone without issues, tag the real release:
+   `git tag vX.Y.Z && git push origin vX.Y.Z` — that's what triggers the
+   signed stable release build.
+
+Do **not** use leftover `dev` / `beta` branches as integration trunks.
 
 ## Tracks, from a user's perspective
 
@@ -59,14 +55,15 @@ bakery update --all            # pull the latest build on your current track
 
 | Track  | What it is | Published from |
 |--------|-----------|-----------------|
-| `stable` | The last tagged release | `main`, on a `vX.Y.Z` tag push |
-| `beta` | Current stabilization freeze | `beta`, on every push |
-| `dev` | Bleeding edge | `dev`, on every push |
+| `stable` | The last tagged release | a `vX.Y.Z` tag |
+| `beta` | Latest release candidate | a `vX.Y.Z-rc.N` tag |
+| `dev` | Bleeding edge | `main`, on every push |
 
-Dev/beta versions are auto-computed (`X.Y.Z-dev.<timestamp>+<sha>` /
-`-beta.…`) from the latest published stable tag, so they always sort as
-newer than what you have installed — no manual version bumping needed when
-pushing to `dev` or `beta`.
+Dev versions are auto-computed (`X.Y.Z-dev.<timestamp>+<sha>`) from the
+latest published stable tag, so they always sort as newer than what you
+have installed — no manual version bumping needed. Beta versions are just
+the RC tag itself (already valid semver, already sorts below the real
+release it's a candidate for).
 
 ## Local development
 
@@ -77,14 +74,22 @@ cargo test --release --workspace
 
 ## CI
 
-- `dev-release.yml` — triggered on push to `dev`.
-- `beta-release.yml` — triggered on push to `beta`.
-- `release.yml` — triggered on a `v*` tag push, cuts the actual stable release.
+Intended single-trunk wiring (see
+[bread-ecosystem's docs/release-channels.md](https://git.breadway.dev/Breadway/bread-ecosystem/src/branch/main/docs/release-channels.md)):
 
-All CI runs on a self-hosted runner; nothing runs automatically on plain
-commits or PRs beyond the track builds above. See
-[bread-ecosystem's docs/release-channels.md](https://git.breadway.dev/Breadway/bread-ecosystem/src/branch/main/docs/release-channels.md)
-for the full policy, including how a new product gets wired onto these tracks.
+- push to `main` → dev-track build
+- `vX.Y.Z-rc.N` tag → beta-track build
+- `vX.Y.Z` tag → signed stable release
+
+`release.yml` already fires on a `v*` tag push. `dev-release.yml` and
+`beta-release.yml` are leftover from the old three-branch model and still
+trigger on the `dev` / `beta` branch names — they have not been rewritten.
+Follow the cycle above; do not treat those branches as current, and do not
+rewrite the leftover workflows unless you are deliberately migrating CI.
+
+`check.yml` runs clippy + test on `feature/**` and `fix/**` branches.
+
+All CI runs on a self-hosted runner.
 
 ## Questions