doc: one execution path for index peeks

A fast-path index peek walks its arrangement cursor inline on the timely
worker that received it, to completion, with no preemption point. A large
scan therefore holds that worker for its full duration, so dataflows are
not scheduled, commands are not handled, and every peek behind it waits.
Three separate efforts have attacked this from three directions, and the
combination is more mechanism than the problem needs.

Record the design that replaces them with one execution path: a single
budgeted scan that both drivers step, promoted to a tokio task holding a
semaphore permit once it outruns its inline budget, with the peek response
stash as a state transition of that scan rather than a restart of the
walk. The document states the contracts the stack implements, the four
parameters and their scopes, the metrics that make engagement observable,
what cancellation must do in five states, and what remains unknown.

It sits at the top of the stack rather than the bottom, because its
Added and Deleted sections describe the end state the branches below it
reach. Reading it against a tree that already contains them is the reading
that can be checked.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: antiguru