doc: one execution path for index peeks

Design document for unifying how a fast-path index peek is executed.

Before the stack below it, an inline peek walked the arrangement until it had
collected a threshold of bytes, then discarded that work and deferred to the
stashing path, which walked the same prefix again. The document argues for one
scan type with two placements, and for treating the stash as a state transition
of a single scan rather than a restart of a different one. It also records what
the scan's budget may be denominated in: consumed cursor positions, not elapsed
time.

The document sits at the top of the stack so that it describes what the PRs
beneath it actually built rather than what they were expected to build.

Author: antiguru