Decide where guides, explanation and tutorials live

## What to decide

Where each kind of user-facing document lives: **guides** (migration guides
included), **explanation**, and **tutorials**. Reference is not in question —
docs.rs renders it and that is what docs.rs is for. The question is everything
that is not reference, and whether answering it needs a documentation site of
our own.

The goal is a recorded answer per kind, not a preference. "A guide lives here,
explanation lives there, a tutorial lives there, and this is why" — enough that
the next document does not reopen the question.

## Why this is a separate issue

#381 forced the question for one document and settled it narrowly. The
composition guide moved into `tears::reducer`'s module docs on the rule
**content lives where its subject is**, supported by the observation that this
repository is primarily for contributors rather than users.

That rule works whenever a document has an owning module. It has nothing to say
about a document that does not, and the repository already holds the standing
counterexample: a migration guide is about a version step across the whole
crate, so no module owns it. Today `docs/migrations/0.10-to-0.11.md` is pulled
in under `cfg(doctest)` purely so its snippets are compiled — it is never
rendered, so a reader upgrading has no docs.rs route to it at all.

So the rule #381 adopted is not wrong, it is partial. Deciding the remainder is
this issue.

## What the same question looks like under Diátaxis

Using the four kinds as a checklist rather than as a commitment to the
framework:

- **Reference** — module and item docs. Settled: docs.rs.
- **Explanation** — the composition guide is this. Now on `tears::reducer`.
The crate root's "Architecture" section and its two-ways-to-write-a-program
paragraph are also this.
- **Guide / how-to** — migration guides are this. Also the crate root's
"Optional Features" and "Observability" sections, which are steps toward a
goal.
- **Tutorial** — the crate has none today. The crate root's `Example` block is
a skeleton with no learning arc, and the `examples/` directory is worked code
rather than a guided lesson.

Two things follow. The crate root is currently all four kinds on one page —
accepted as pre-existing and deliberately left outside #381's scope, but it
does not go away. And a decision that only covers explanation leaves guides and
tutorials unplaced.

## Evidence already gathered, so it is not re-derived

Collected while deciding #381. Dated, and worth re-checking rather than
trusting if this issue is picked up much later.

**docs.rs has two surfaces, and they are easy to conflate.** The rendered
documentation (`docs.rs/{crate}/{version}/{crate}/`) and the package browser
(`docs.rs/crate/{crate}/{version}/source/`) are different things. The package
browser shows every file the `.crate` ships, so packaged markdown is reachable
— but as raw text with line numbers, not as a rendered document. It is a file
browser, and the rendered docs reach it only through a small top-bar link.

**Most crates without a documentation site publish no guide pages at all.**
`regex`, `reqwest`, `itertools`, `crossterm`, `indexmap` and `axum` put
everything in `lib.rs` and the module docs. Of the crates surveyed that do
publish guide pages, the mechanisms differ on two independent axes — where the
prose lives, and whether the pages are feature-gated:

| crate | prose in | gate |
| --- | --- | --- |
| `rustls` 0.23.43 | `.rs`, as `/*! … */`, under a permanent `pub mod manual` | none |
| `clap` 4.6.6 | `.rs`, as `//!`, with `include_str!` for example code | `unstable-doc` |
| `nom` 7.1.3 | `.md`, kept in the repository and shipped | `docsrs` |

Two of the three add a feature that exists only to render pages, and then name
it in `[package.metadata.docs.rs]`.

**Our own documents, measured by opening fence.** `README.md` has 11 blocks, 4
of which would compile as doctests if it were pulled into rustdoc.
`docs/migrations/0.10-to-0.11.md` has 12 blocks and already pays 9 of them
under `cfg(doctest)`, so rendering it would add visibility rather than
compilation. The composition guide had none, which is part of why moving it
cost so little.

## Options

Not exhaustive, and not ranked.

1. **docs.rs only, by the owning-module rule.** What #381 established, extended
to say explicitly that a document with no owning module gets no page — its
route is `CHANGELOG.md`, `README.md` or the repository. Migration guides stay
as they are.
2. **docs.rs, plus a namespace for documents with no owner.** A permanent
`tears::guide` (or similar) holding what the owning-module rule cannot place.
Costs a public path that exists only to carry pages, and an entry in
`docs/api-guidelines.md` saying so.
3. **A site of our own,** with docs.rs kept strictly reference. Removes the
quadrant-mixing problem at the root, and gives tutorials a home they have
nowhere else. Costs a second surface to build, host, version and keep in
step with releases.
4. **Split by kind.** Explanation on docs.rs where a module owns it; guides and
tutorials on a site.

## What would close this

- A statement, per kind, of where it lives and why, recorded where a
contributor writing the next document will find it — `docs/api-guidelines.md`
or `CONTRIBUTING.md`.
- An answer for migration guides specifically, since they are the case the
current rule cannot place.
- A decision on whether `docs/` stays contributor-only. It nearly is today:
after #381 the only user-facing document left there is `docs/migrations/`.

## Out of scope

Re-opening #381. The composition guide's placement is settled; this issue is
about the kinds it did not cover.