Seats held by assignments, one assignment per module per node, and 0113's bottom of the stack

Decided with the author:
- A seat is held by one assignment, not claimed by a definition. A definition says which seats a module
  can hold; an assignment says which it does. The store module can run on every node and one assignment
  holds mesh-store; moving a role changes an assignment, never a definition. The foundation's seats name
  what the mesh itself uses and route no consumer — database and amqp consumers use co-location, the
  holder included. This replaces the wrong rationale that the foundation's store is "provider to nobody",
  which contradicted ADR 0078 and to-be 21. 0079's one-postgres rule becomes one mesh-store holder.
- A module is assigned at most once to a node. The instance identity in 0112 and 27 is withdrawn, and the
  login-length problem with it.

Review fixes to 0113:
- The bottom of the stack: the vault is installed as soon as the shared runtime base exists, and genesis
  generates everything needed until then — including the permanent controller's, the control-node
  agent's, the builder's and the broker provisioner's bus accounts, and the controller's store login.
  Genesis creates those accounts until the broker's provisioner runs and adopts them.
- Genesis's values are delivered recorded as the mesh's own, so 0092's never-replace rule for operator
  values does not make them unrotatable.
- Backend-issued secrets (a forge's once-only API token) enter through the vault. Non-module parties
  (the controller's logins, node agents' accounts) are answered the same way, the controller asking on
  their behalf; an enrolment token reaches the controller only as what verifies it.
- A secret with no provisioner to apply it is marked not rotatable by the mesh and refused, instead of
  a restart reported as done. Unused password generators in six provider clients are removed, and a
  catalogue scan checks no module mints.
- Rotation's lock-out cases (offline reader, bus account owner, restarted provisioner) are recorded as
  open, with overlap and re-confirm-with-safeguards as the two answers, to be chosen before acceptance.

0110, 0111 and 26 are marked proposed: they changed in meaning and are under review, and an accepted
record must not rest on proposed ones. To-be 23 and the glossary are restored to main; they change when
these records are accepted.

00-META/glossary.md

@@ -44,22 +44,15 @@ another — and a mesh you cannot name precisely is a mesh two people describe d
 
 ## How modules relate to the mesh
 
-- **seat** — a named role at a scope (node / site / mesh), held by a module assignment, from a
-  **closed set** the mesh defines: a claim naming a seat outside the set is refused. A seat may
-  **deliver a provision**, and its holder is then the mesh's answer for it when several modules
-  provide it ([ADR 0110](../02-DECISIONS/0110-a-seat-is-a-module-assignment-from-a-closed-set.md)).
-  The set, with who holds each seat, is the overview of what a mesh has
-  ([26 — The seats](../03-DESIGN/01-to-be/26-the-seats.md)). A seat has a **capacity**: a
-  capacity-1 seat is exclusive (one holder); a higher-capacity seat is a **bench** (several holders
-  coexist).
+- **seat** — a named position at a scope (node / site / mesh) with a **capacity**. A capacity-1 seat
+  is exclusive (one holder); a higher-capacity seat is a **bench** (several holders coexist).
 - **claim** — a module taking a spot on a seat. `claims: [{name, scope}]` in a manifest. A
   mesh-scoped exclusive claim is how the mesh says "there is one of me". A foundation seat is
   named after the server it guards: the `mesh-controller`, `postgres` and `lavinmq` modules claim
   the `mesh-controller`, `mesh-store` and `mesh-broker` seats ([ADR 0079](../02-DECISIONS/0079-the-foundation-seats-are-named-after-their-servers.md)).
 - **provision** — a service one module `provides` and others `require`; the mesh resolves a provider
-  and wires the two with an endpoint and a credential. A provision is a service you offer, a seat
-  is a role you occupy, and the two meet where a seat delivers a provision: occupying the seat is
-  what makes a module *the* provider of it.
+  and wires the two with an endpoint and a credential. This is separate from seats: a provision is
+  a service you offer, a seat is a slot you occupy.
 
 ## How this page is kept