docs(guide): spell out the two-token chart form

Field-test spec gap: the tap example said the series is "chartable by its
name", which reads as \`aura chart spread\` — that refuses, because no run is
named after a tap. The handle addresses the run, \`--tap\` selects within it;
both tokens are now shown, with the failing reading named so it is not
re-derived.

refs #309

docs/authoring-guide.md

@@ -334,9 +334,12 @@ The built blueprint carries a `taps` array naming the resolved wire
 (`{"name":"spread","from":{"node":<sub's index>,"field":0}}` — the name is
 addressed, the index is resolved *for* you). A single `aura exec <blueprint>`
 then constructs a recorder at that point and persists the `spread` series as a
-`ColumnarTrace` in the run's trace store, chartable by its name — which the
-run prints for you as `trace_name` on its stdout line, so it need not be
-guessed. A tap is inert
+`ColumnarTrace` in the run's trace store. The run prints the handle it wrote
+under as `trace_name` on its stdout line, so it need not be guessed; chart it
+with `aura chart <trace_name>` (all of the run's taps) or
+`aura chart <trace_name> --tap spread` (just this one). Note the two tokens
+are different things: the handle addresses the RUN, `--tap` selects a tap
+WITHIN it — `aura chart spread` refuses, because no run is named `spread`. A tap is inert
 in a campaign member run (no per-cell recorder) — it is a single-run
 observation surface (or, per campaign, what a nominee's `persist_taps`
 re-run records, §3).