Scope the resolver run-once guarantee to questions, not resolver bodies

Each question is asked exactly once per call, but on the multi-round-trip
form an eliciting resolver's body runs again to consume its answer, and a
resolver that answered without asking may run again whenever the call
resumes. The tutorial info box, its recap bullet, and the refund_desk
caveats now say exactly that, so authors don't hang side effects on a
runs-at-most-once reading that only holds for the synchronous form.

Author: maxisbey

docs/tutorial/dependencies.md

@@ -122,18 +122,20 @@ That's the right default for a precondition: no answer, no order. When declining
     multi-round-trip `tools/call` - the server returns it, the client's `elicitation_callback`
     answers it, and the `Client` retries the call for you (**[Multi-round-trip requests](../advanced/multi-round-trip.md)**). On
     **2025-11-25** and earlier it is a synchronous elicitation request mid-call. Each question is
-    asked exactly once per call; a resolver that answered *without* asking, like `check_stock`,
-    may run again when the call resumes after a question. When it resumes, each answer is matched
-    back to its question, so an eliciting resolver must derive its question deterministically from
-    the tool's arguments and earlier answers - a per-call generated value (a `default_factory` id,
-    a timestamp) is re-derived on each round and must not appear in a question the answer is meant
-    to bind to.
+    asked exactly once per call - a guarantee about the question, not the resolver. In the
+    multi-round-trip form an eliciting resolver runs again to consume its answer, so code before
+    its `return Elicit(...)` runs on the asking round and again on the answering one; a resolver
+    that answered *without* asking, like `check_stock`, may run again whenever the call resumes
+    after a question. When it resumes, each answer is matched back to its question, so an
+    eliciting resolver must derive its question deterministically from the tool's arguments and
+    earlier answers - a per-call generated value (a `default_factory` id, a timestamp) is
+    re-derived on each round and must not appear in a question the answer is meant to bind to.
 
 ## Recap
 
 * `Annotated[T, Resolve(fn)]` on a tool parameter: the SDK runs `fn` and injects its return value.
 * A resolved parameter is invisible to the model and cannot be supplied by a client. Values the model must not invent - prices, identities, permissions - belong here.
-* A resolver's parameters are resolved the same way: the `Context`, another `Resolve(...)`, or a tool argument by name. The graph runs each resolver at most once, however many consumers it has; a resolver that never asked may run again when a call resumes after a question.
+* A resolver's parameters are resolved the same way: the `Context`, another `Resolve(...)`, or a tool argument by name. The graph runs each resolver at most once per round, however many consumers it has; each question is asked exactly once, an eliciting resolver runs again to consume its answer, and a resolver that never asked may run again when a call resumes.
 * Bad graphs fail at registration with `InvalidSignature`, not mid-call.
 * Return `Elicit(message, Model)` to ask the user, only when you have to. Unwrapped annotations abort on decline; `ElicitationResult[T]` lets the tool branch.
 

examples/stories/refund_desk/README.md

@@ -62,6 +62,8 @@ uv run python -m stories.refund_desk.client --http
   within a round each resolver runs at most once, keyed by function identity.
   Across 2026 rounds only *elicited* outcomes persist (in `requestState`); a
   resolver that resolves without eliciting is pure and may re-run each round.
+  An eliciting resolver's body runs again too — once to ask, once more to
+  consume its answer.
   An answer is matched back to its question when the call resumes, so an
   eliciting resolver must derive its question deterministically from the
   tool's arguments and earlier answers; a per-call generated value (a