Design 47 G §717: a follower hears its seat's holder from the seat-holders view

A seat's view is said on its holder's module subject, so a follower must know
the holder; asking for it every 5 seconds was polling and kept a holder that
moved. It now follows the seat-holders view as A-295's holder function does,
reached from the catalog half's claim, and re-follows when the holder changes.

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

03-DESIGN/01-to-be/47-milestones/G-21-provider-and-revert-ask.md

@@ -307,7 +307,7 @@ design's choice within the record it cites, tested against [the principles](../.
 - §717 **The status view's answers are a view of the seat `mesh-delivery-view`, the assigner's asks and wants are
   views of the seat `mesh-wants`, and a follower finds each by its seat and starts without it.** (ADR 0540 §1, §6;
   ADR 0429 §3; ADR 0567 §5, §6; ADR 0571 §6; ADR 0565; ADR 0539 §16; ADR 0596; §7, §200, §428, §532, §616, §699,
-  §710, A-126, A-131, A-175, A-178, A-210) This answers developer J27's question of 2026-11-12, met building A-210
+  §710, §614, A-126, A-131, A-175, A-178, A-210, A-295) This answers developer J27's question of 2026-11-12, met building A-210
   and A-296 (G-22): A-210 has a part find another module as the holder of the seat it holds, but the status view
   claims no seat while the teller follows its `answers` by its module name, and the assigner holds two seats while
   the teller follows its `asks` by its module name. It completes A-175 and A-178 for both views.
@@ -340,25 +340,40 @@ design's choice within the record it cites, tested against [the principles](../.
     `seat:mesh-module-assigner.views.assignments` in place of the three `mesh-delivery-assigner.views` entries, and
     its `invokes` loses `assigner_read_asks`, `assigner_read_wants` and `assigner_read_assignments`. Neither part's
     code names the assigner or the status view (§7, §428).
-  - **A follower starts before the holder is known.** mesh-sdk's `views.ProcessReader` gains `FollowSeat`, given a
-    seat and a state: it returns at once a picture that reads as empty, its follower not ready, and never fails for
-    want of a holder. In its own goroutine it asks `seatlist.HolderOf` for the seat through the process's calls; a
-    failed ask is said in the process's journal, naming the seat and the error, and asked again 5 seconds later,
-    until it answers or the process stops. Meanwhile the follower's status names the seat in place of its owner,
-    waiting since the start, and past five minutes the reader writes §200's `view-waits` naming the seat and the
-    state, cleared when the first view arrives. Once the seat's holder H is known it follows as `Follow` does after
-    `Start` (§532): the first view asked of H's tool named for the state, then H's views family. The holder found is
-    kept for the life of the process, and a new holder is followed from the follower's next start. The teller's two
-    follows and the status view's three go through `FollowSeat`, each apart, so the teller raises the assigner's
-    asks whether or not the status view's answers are read (issue 1906, as today). The builder's and the checker's
-    own loop for the assignments, buildrun's `AssignerHolder`, goes: both follow `assignments` through `FollowSeat`.
+  - **What the seat form puts on the bus.** A seat's view is said where its holder says it, on the holder's own
+    subject `mesh.mod.<holder>.event.views.<state>`, and the grants part resolves a `consumes` entry
+    `seat:<seat>.views.<state>` to that subject for the seat's holder on record, granting nothing while the seat has
+    none (§616). The subject is module-scoped, so a follower must know the holder, and follows it as it moves.
+  - **A follower finds and re-finds the holder from the seat-holders view.** mesh-sdk's `views.ProcessReader` gains
+    `FollowSeat`, given a seat and a state, and the holder function A-295 gives a part, which answers from what the
+    part last heard of the seat `mesh-module-assigner`'s view `seat-holders`. The part follows that view as the tool
+    runner does (§616): the module that claims `mesh-module-assigner` is read from the catalog half the part follows
+    (§614, the trunk's entry whose manifest `claims` the seat), so no code names the assigner's module; the view is
+    named `seat:mesh-module-assigner.views.seat-holders` in the part's `consumes`, its first view asked of the
+    claimant's tool `seat-holders`, and a catalog revision naming another claimant drops it and follows the new one
+    (§532). `FollowSeat` returns at once a picture that reads as empty, its follower not ready, and never fails for
+    want of a holder. At each change of the seat-holders view it reads the seat's holder: on a first holder it follows
+    as `Follow` does after `Start` (§532), the first view asked of the holder's tool named for the state, then its
+    views family; on another holder it drops the view of the old one and follows the new one, the picture handing on
+    the new holder's state whole; with no holder it keeps the picture it has and follows nothing. Nothing is asked
+    again on a timer. While no holder is followed the follower's status names the seat in place of its owner, waiting
+    since its start or since its holder left, and past five minutes the reader writes §200's `view-waits` naming the
+    seat and the state, cleared when a holder's first view arrives. The teller's two follows and the status view's
+    three go through `FollowSeat`, each apart, so the teller raises the assigner's asks whether or not the status
+    view's answers are read (issue 1906, as today); the teller gains the catalog half's reader of §614 for this. The
+    builder's and the checker's own loop for the assignments, buildrun's `AssignerHolder`, which asks every 5 seconds,
+    goes: both follow `assignments` through `FollowSeat`. `seatlist.HolderOf`'s call stays for a caller that asks
+    once, as A-210 has it.
 
   Why: ADR 0540 §1 already names the seat the status view holds, and §616 and §699 give a view named by its seat;
-  `asks` goes where the kinds it holds belong, its proposal kind kept with them so the teller follows one view, and
-  the holder is found as A-210 has it, asking again and never stopping a start (principles 1, 3, 7 and 8). How it is
-  checked: unit (mesh-sdk `views`), a `FollowSeat` whose holder ask fails twice returns at once, writes `view-waits`
-  naming the seat past five minutes, then takes its first view from `<holder>.<state>` and hears the holder's family;
-  unit (manifest validator), `seat:mesh-delivery-view.views.answers` and `seat:mesh-wants.views.asks` accepted, a seat
-  view of a state without `view` refused; whole (teller), started before any module holds `mesh-wants`, it raises an
-  assigner's ask once the holder is placed, and takes an answer the status view writes; the code review, no module
-  name of the assigner or the status view in the teller's, the status view's, the builder's or the checker's code.
+  `asks` goes where the kinds it holds belong, its proposal kind kept with them so the teller follows one view. The
+  holder is heard from the seat-holders view as A-295 has it, never asked on a timer, and a moved holder is followed
+  as it moves (principles 1, 3, 7 and 8). How it is checked: unit (mesh-sdk `views`), a `FollowSeat` with no holder
+  returns at once and writes `view-waits` naming the seat past five minutes; a seat-holders change naming a holder
+  takes its first view from `<holder>.<state>` and hears its family; a second change naming another holder drops the
+  first and follows the second; no ask is made between changes. Unit (manifest validator):
+  `seat:mesh-delivery-view.views.answers` and `seat:mesh-wants.views.asks` are accepted, and a seat view of a state
+  without `view` is refused. Whole (teller): started before any module holds `mesh-wants`, it raises an assigner's
+  ask once the holder is placed, and takes an answer the status view writes. The code review: no module name of the
+  assigner or the status view in the teller's, the status view's, the builder's or the checker's code, and no
+  timer that asks for a holder again.