Refusal messages taught the old API

[0-jake-0]

Stacked on #767 → #766 → #765 → #764 → #763 → #762 → #761 → #760 → #759.

What this changes

The refusal text is the teaching surface — the one thing a user reads at the moment they're confused — and it was written before both quoted! (#765) and #[op(emit_cfg)] (#767) landed, so it taught neither.

It recommended the manual two-step func! + .with_src(..) form rather than quoted!, said nothing about declaring captures (the case most likely to have caused the refusal), and advised recording data configs — which concrete ones now do themselves, so following it would send a reader to fix something that isn't broken.

Now:

- node 2 (Map): `map`'s closure was not quoted, so the engine erased it.
  Write `quoted!(<upstream> => map(..))` — or, if it captures, declare
  what it captures: `map([threshold] move |v| ..)`.

Every closure a generated graph contains has to be quoted, because the
engine erases closures and no traversal can recover one. Data configs
mostly look after themselves — only `fold`/`scan` seeds, whose type is
generic, still need `.with_cfg(&seed)`.

The op's own build name is interpolated, so the suggestion names the method the user actually called rather than a generic map.

How it was verified

• cargo fmt --all
• cargo lint ✅ — cargo lint-all not run (--all-features needs CMake ≥3.30 for aeron and protoc for etcd; documented prerequisites, unrelated to this diff).
• --all-features blocked as above. Full default suite plus the broad feature set — green. Doctests green.
• Covered by tests

Assertions updated across three tests. The unit test now also asserts the footer does not carry blanket with_cfg advice — the specific way it was wrong, pinned so it can't drift back.

Notes for the reviewer — and a finding that outranks this PR

While writing this I tested something I'd asserted earlier without checking, and I was wrong about it. quoted!'s => syntax buys nothing.

I'd justified the => form on the grounds that a proc macro loses verbatim source. That part holds. But I never checked whether a concrete QuotedFn<F> parameter preserves closure inference — the map_q(func!(..)) shape. Measured:

Form	Unannotated closure	Chainable
.map(|i| i*2) — no quotation	✅	✅
quoted!(ticks => map(|i| i*2))	❌ Fn is not general enough	❌
.map_q(func!(|i: &u64| i*2))	❌ same error	✅

Both quotation forms need the annotation equally — func! binds the closure with no expected type in sight, so quoted! inherits the same HRTB failure. So the => grammar costs chainability and buys nothing over a _q method twin.

#[op(fluent)] already generates the fluent method, so generating a _q twin is a derive flag plus one trait-declaration line per closure-config op — mechanical, and it would let func! be the only vocabulary:

let out = ticks.map_q(func!(|i: &u64| i * 2))
               .filter_value_q(func!(|v: &u64| *v > 4));

That deprecates quoted! — which #765 and #766 introduce. I have not built it, because it invalidates two open PRs in this stack and that's a call for the repo owner, not something to do unilaterally on top of nine unreviewed layers.

Stack: eleven PRs, none reviewed, ten chained on #759.

---

Generated by Claude Code

[0-jake-0]

Superseded by #769, which squashes this whole stack (#759–#768) onto main as a single reviewable change.

The corrected refusal messages are carried forward. Closing to keep the queue readable; no content is being dropped.

---

Generated by Claude Code