docs: drop planned --snapshot flag; pkg.pr.new owns ephemeral publishing

After reviewing realistic prerelease workflows: between bumpy channels
(managed long-running release lines) and pkg.pr.new (ephemeral previews,
canaries, branch snapshots), real-world use cases are covered. No need
for an in-bumpy snapshot mechanism that would compete with the
recommended tool.

Expand the rule-of-thumb table to cover per-commit canaries and ad-hoc
branch snapshots. Reinforce the pkg.pr.new pointer in the day-to-day
workflow section so readers see it at the natural moment ("I want to
install this PR before merging").

Author: theoephraim

docs/prereleases.md

@@ -14,17 +14,19 @@ No `pre enter` / `pre exit` commands. No mode files in your repo. No hidden stat
 
 Channels are designed for **long-lived release lines** — an ongoing `next` / `beta` / `rc` cycle that accumulates changes over days or weeks before promotion to stable. They carry per-cycle state in your branch and your `.bumpy/<channel>/` directory, and they're worth setting up when you expect to ship multiple prereleases through the same cycle.
 
-**For per-PR preview releases, use [pkg.pr.new](https://pkg.pr.new) instead.**
+**For anything short-lived or ephemeral, use [pkg.pr.new](https://pkg.pr.new) instead.**
 
-pkg.pr.new publishes an ephemeral package from any open PR, gives you an install URL pinned to the PR's commit, and disappears when the PR closes. It's purpose-built for "let me try this PR before merging" workflows — no version planning, no branch discipline, no consumed bump files. Bumpy channels would be the wrong tool for that job: you'd be polluting your channel branch with throwaway state for every PR.
+pkg.pr.new publishes throwaway packages from any PR, commit, or branch — no version planning, no branch discipline, no bump files. It pairs naturally with bumpy: bumpy owns the managed release lines, pkg.pr.new owns the ephemeral previews. Between the two, most teams need nothing else.
 
 Rough rule of thumb:
 
-| You want…                                                 | Use                                   |
-| --------------------------------------------------------- | ------------------------------------- |
-| Preview a single PR for review                            | [pkg.pr.new](https://pkg.pr.new)      |
-| Ship a `1.2.0-rc.N` line for weeks of integration testing | Bumpy channels (this doc)             |
-| One-off canary from `main`                                | (Planned: `bumpy publish --snapshot`) |
+| You want…                                                 | Use                              |
+| --------------------------------------------------------- | -------------------------------- |
+| Preview a single PR for review                            | [pkg.pr.new](https://pkg.pr.new) |
+| Per-commit canary from `main`                             | [pkg.pr.new](https://pkg.pr.new) |
+| One-off snapshot from a branch for ad-hoc testing         | [pkg.pr.new](https://pkg.pr.new) |
+| Ship a `1.2.0-rc.N` line for weeks of integration testing | Bumpy channels (this doc)        |
+| Parallel `@next` + `@beta` lines for different audiences  | Bumpy channels (this doc)        |
 
 ---
 
@@ -141,6 +143,8 @@ PR authors do nothing different. They:
 
 Bump files don't carry channel metadata. The branch they land on determines the channel; their location tracks whether they've shipped.
 
+> Reviewing a feature PR and want to install it before merge? That's [pkg.pr.new](https://pkg.pr.new)'s job, not a channel publish. Channels only kick in once a PR has merged into the channel branch.
+
 ### Versioning a prerelease
 
 When a feature PR merges to `next`:
@@ -366,7 +370,6 @@ The directory used to hold shipped bump files matches the channel name: `.bumpy/
 
 These are intentionally out of scope for the initial channel feature. If any of these is a blocker for you, please open an issue.
 
-- **Per-PR preview releases** — use [pkg.pr.new](https://pkg.pr.new) instead. It's purpose-built for ephemeral per-PR packages and pairs well with bumpy. See [When to use channels — and when not to](#when-to-use-channels--and-when-not-to) above.
-- **One-off snapshot publishes from `main`** (`0.0.0-snapshot-<sha>`) — planned as a separate `bumpy publish --snapshot` flag, not via channels.
+- **Ephemeral / preview / canary releases** — use [pkg.pr.new](https://pkg.pr.new) instead. It owns short-lived publishing (per-PR, per-commit, per-branch); bumpy channels are deliberately scoped to managed long-running release lines. See [When to use channels — and when not to](#when-to-use-channels--and-when-not-to) above.
 - **Workflow-dispatch one-off prereleases** — planned as a complement to channels, for teams that want occasional prereleases without a dedicated branch.
 - **Per-bump-file channel routing** — declaring `channel: beta` inside a bump file's frontmatter. Not planned; channels stay branch-derived to keep the mental model simple.