Hold no requirer of bus state for a bus build that waits for a yes

The assigner's provider rule read the phase of the bus module's newer want,
so a yes not yet asked held every module asking bus state (issue 1966,
note 150); milestone G reads what runs. Also name the tracker of the
review-author stopgap.

Claude-Session: https://claude.ai/code/session_01JG73KK8HD1gufnqyFxMFdW

03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md

@@ -1628,7 +1628,13 @@ per module and node from the keys:
 - **A build before its want.** No want names a fingerprint whose build is not done; a module whose build waits
   is named by nothing and fails nothing (rule 1; ADR 0539 §18).
 - **A provider before its consumers.** A module's new fingerprint is wanted on a node only while every provider
-  it requires runs healthy (rule 5).
+  it requires runs healthy (rule 5). From milestone G a provider runs healthy while the build it runs is healthy, as
+  the node-engine seat's `running` says it, whatever a newer want of it waits for: a bus module whose new build waits
+  for the operator's yes (its have's phase `waiting-yes`) still serves bus state from the build that runs, so the
+  provision `bus-state` holds no requirer for it (ADR 0614 §5, ADR 0429 §6). The rule reads what runs, never the phase of
+  a want not yet applied: on 2026-11-09 a yes not yet asked on the bus held the delivery of every module asking bus state
+  (issue 1966, note 150). How it is checked: whole (assigner), a provider whose new want waits for a yes, with its old
+  build running healthy, holds no consumer's want, and one whose running build is unhealthy holds it.
 - **The canary before the rest.** A new fingerprint goes to the module's canary first, and to its other nodes
   once it runs healthy there, at most `step` of them ahead when `step` is above zero (rules 3 and 4).
 - **A credential and a composition before the want.** The module's credential and grant are written when its
@@ -3715,7 +3721,8 @@ B0's own choices, each checked by the rows of *How it is checked* below:
 - **How the runner knows a review's caller is the commit's author.** ADR 0666 §12 refuses a review from the commit's
   author; the forge names the author by its forge account and the runtime proves the caller's bus account, and no
   record or design says which forge account belongs to which bus identity. Until one does, the runner refuses a
-  review whose caller's identity carries the name the commit's forge account carries, said as such in its refusal.
+  review whose caller's identity carries the name the commit's forge account carries, said as such in its refusal;
+  issue 1966 tracks it (note 157).
 - What a process started by a node-engine that hands no fingerprint does beyond saying `own build unknown`, for a part
   other than the indexer.
 - The caps' and the growth's numbers are estimates (*Two graphs, one source of truth*); the fill tools read the real