Research 016: survey how each provider can rotate a credential

Overlap as drafted in 0113 would have deleted consumer data: seven of
eight providers name the resource after the login and five drop it on
remove. Rotation is now undecided in 0113 and to-be 27, pending the
survey. Also: a requirement naming a seat resolves to its holder, a
person chooses among remaining candidates at assignment, the controller's
secrets are requirements of its definition, genesis seals to the
control-node key, and moving the vault or broker is break-glass.

03-DESIGN/01-to-be/26-the-seats.md

@@ -8,7 +8,7 @@ code:
   - mesh-controller cmd/mesh-controller/source.go
   - mesh-controller internal/inventory/migrations/0032-a-source-may-live-on-a-seat.sql
   - mesh-catalog modules/gitea/module.json
-updated: 2026-09-25
+updated: 2026-09-26
 decisions:
   - 02-DECISIONS/0110-a-seat-is-a-module-assignment-from-a-closed-set.md
   - 02-DECISIONS/0111-a-build-source-is-on-the-git-seat-or-external.md
@@ -78,7 +78,8 @@ merges.
 controller, the store holding its records, the broker carrying its bus. **They route no consumer.** The
 store and broker modules may run on other nodes too. A database or `amqp` consumer is served by
 co-location, from whichever runs on its own node, the seat's holder included
-([23 — Choosing a provider](23-choosing-a-provider.md)).
+([23 — Choosing a provider](23-choosing-a-provider.md)). A requirement cannot name one of them,
+because they deliver nothing.
 
 ## A seat that delivers a provision
 
@@ -86,19 +87,18 @@ co-location, from whichever runs on its own node, the seat's holder included
 the npm registry, git and the vault are each one per mesh by decision. A seat that delivers a
 provision may only be held by an assignment of a module that provides it, at the seat's scope.
 
-**Its holder answers for that provision.** A requirement for it resolves, in order, to:
+**A requirement may name the seat, and then its holder answers.** Naming the seat asks for *the
+mesh's* one, so the holder answers **even when another provider runs on the consumer's own machine**,
+and nobody is asked anything. With the seat unheld, the requirement is refused, naming the seat. A
+second provider can run beside the holder and harm nothing. A forge assignment holds
+`npm-package-registry`, and an npm proxy may provide the same provision on another machine. A builder
+that names the seat is still served by the forge, without anybody pinning it.
 
-1. the provider the consumer's node was pinned to, because a consumer coupled to one provider's
-   contents has said so ([23 — Choosing a provider](23-choosing-a-provider.md));
-2. the holder of the seat, **even when another provider runs on the consumer's own machine**;
-3. otherwise nothing, and the requirement is refused, naming the unheld seat.
-
-Co-location, which answers first for every other provision, does not apply here: a seat says which
-one is the mesh's, and co-location answering first would let any second provider on a consumer's
-machine take over for that consumer, silently. So a second provider can run beside the holder and
-harm nothing. A forge assignment holds `npm-package-registry`. An npm proxy may provide the same
-provision on another machine, and a module requiring an npm registry is still served by the forge,
-without anybody pinning it.
+**A requirement that names no seat resolves as any other**: a pin, the provider on the consumer's own
+machine, the only provider. If several remain and none is local, a person chooses when the module is
+assigned. The candidates are listed with the seat's holder suggested first, and the answer is recorded
+as the assignment's pin ([27](27-a-module-requires-the-mesh-resolves.md)). Nothing is guessed, and
+nothing changes silently because a second provider happened to appear nearby.
 
 **Moving the role is changing which assignment holds the seat.** No definition changes and nothing is
 unassigned: the forge keeps running, and keeps holding `git`, when its npm role moves. A module can
@@ -106,9 +106,9 @@ take the role only if its definition says it can hold the seat.
 
 **The vault's provision is reserved.** Only an assignment holding `mesh-vault` may provide `secret` at
 all: a definition providing it that cannot hold the seat is refused, an assignment providing it without
-holding the seat is refused, and a pin cannot choose another provider, because there is none. A second
-provider of secrets would be a second place secrets live, which is what the vault being one per mesh
-exists to prevent.
+holding the seat is refused, and a `secret` requirement always names the seat, because there is no
+other provider. A second provider of secrets would be a second place secrets live, which is what the
+vault being one per mesh exists to prevent.
 
 **What a consumer receives is what it required**, the same as for any provision: where the provider
 answers, what it serves, and a credential. A consumer never reads the seat directly. The one exception