doc: describe the permit bound as the fraction it now is

The design document described the permit fraction in nano-fractions of the
worker count. The parameter is a plain `f64` fraction, so the description
matches what an operator sets.

Author: antiguru

doc/developer/design/20260825_peek_execution.md

@@ -406,18 +406,19 @@ Four parameters:
   whose rows are bound for the stash suspends once its accumulation crosses
   `peek_response_stash_threshold_bytes`, by far the smaller trigger at that
   parameter's default, so such a walk yields per batch.
-* **Permit fraction**, default one permit per timely worker, expressed in
-  nano-fractions of the worker count the way Kubernetes expresses a CPU share.
-  How many promoted scans may run at once. It bounds running scans and nothing
-  else, and the queue that forms behind it is a signal rather than a second
-  bound.
+* **Permit fraction**, default `1.0`, a fraction of the timely workers a compute
+  runtime runs. How many promoted scans may run at once, floored at one scan.
+  Expressed as a fraction so the bound scales with the replica rather than being
+  retuned per size. It bounds running scans and nothing else, and the queue that
+  forms behind it is a signal rather than a second bound.
 
 A peek passed over for want of budget is served before the peeks that were served
-ahead of it, which takes two pieces beyond the counters. The sweep records the
-uuid it stopped at and the next sweep rotates the pending peeks to start there, so
-serving them in uuid order alone cannot let a later arrival with a lower uuid take
-a passed-over peek's turn. A stale resume point is harmless, since a uuid that has
-since been answered still names where in the ordering to resume.
+ahead of it, which the pending peeks carry themselves. They are a queue: a sweep
+drains it from the front and returns what it could not retire to the back, so the
+order that survives a sweep is the order the next one owes, and a peek arriving
+later queues behind one that has already waited. Holding them keyed by uuid
+instead would let a later arrival with a lower uuid take a passed-over peek's
+turn, and do so on every activation.
 
 The worker also has to get back to such a peek, and nothing else brings it there:
 the peeks that spent the budget were answered or promoted, and neither leaves an
@@ -651,7 +652,7 @@ Seven layers, bottom to top. The first two have merged.
   its Added and Deleted sections describe the end state the layers below reach.
 
 #38158 is absorbed rather than merged separately. It is unmerged upstream, and the
-`PeekError` type it introduces is what `ScanOutcome::Failed(PeekError)` assumes,
+`PeekError` type it introduces is what the `Err` side of a finished `ScanOutcome` assumes,
 so carrying it as a layer of this stack is what lets every layer above it name a
 structured error at all. Its `merge_peek_responses` precedence is the one this
 design inherits rather than rewrites.