Issue 169: file sharing is a core seat, one per protocol

The operator's call: a node-scoped system seat family (node-nfs-share,
node-smb-share, …) defined by the control plane, one per protocol as
package registries are (ADR 0109), so several modules occupy it and a
machine may hold both.

04-ISSUES/169-a-machine-shares-its-files-and-the-mesh-does-not-know/00-report.md

@@ -39,20 +39,32 @@ Under the mesh as it stands, this arrangement has no expression and one failure
 
 ## The proposal (the operator's, 2026-09-30)
 
-A **file-sharing module** — NFS first, Samba the same shape — that:
+**File sharing is a core seat — a role each machine has, defined by the control plane — and, as
+with package registries (ADR 0109), one seat per protocol, so several modules occupy the family:**
 
-- declares the exported paths as `accesses` (ADR 0051: it owns nothing about them, never creates,
+| seat | scope | delivers | held by |
+|---|---|---|---|
+| `node-nfs-share` | node | `nfs-share` | an `nfs` module |
+| `node-smb-share` | node | `smb-share` | a `samba` module |
+| … (`node-webdav-share`) | node | … | whatever comes next |
+
+Named for their scope (ADR 0121), one holder per node (ADR 0110), each carrying its protocol
+(ADR 0129). A machine may hold both — nfs and samba on ace — and one module may hold several
+(0109: "gitea may hold several seats at once"). Adding a protocol is adding a seat and a
+provision, not widening one.
+
+The holder module:
+
+- declares the exported paths as `accesses` (ADR 0051: it owns nothing about them — never creates,
   chowns or removes), and *which* paths as the assignment's settings (ADR 0046/0112);
 - writes the share configuration (`/etc/exports`, `smb.conf`) as mesh-managed files and drives the
   units, like `dnsmasq`/`sshd` do for theirs;
-- declares its endpoints (`nfs` 2049/tcp, `smb` 445/tcp, …) so the reach — internal, or the LAN
+- declares its endpoints (`nfs` 2049/tcp; `smb` 445/tcp, …) so the reach — internal, or the LAN
   once 154 has an answer — is the assignment's, and converge keeps them open;
-- **defines and holds a node-scoped seat** (`file-share`, one holder per machine, as ADR 0126
-  lets a module do) — the machine's one answer for "where are the files";
-- **provides** `file-share` at mesh scope, serving the export path(s) and protocol, so a consumer
-  on another node `requires` it and reads `${bound:file-share:at}` and the path from its binding
-  instead of a hand-typed mount; a pair credential where the protocol has one (Samba user), none
-  for `sec=sys` NFS.
+- **provides** the seat's provision, serving the export path(s), so a consumer on another node
+  `requires nfs-share` (or `smb-share`) and reads `${bound:nfs-share:at}` and the path from its
+  binding instead of a hand-typed mount — a pair credential where the protocol has one (a Samba
+  user), none for `sec=sys` NFS.
 
 What it would settle: ace's library becomes reachable from the mesh by declaration, the two host
 services get an owner, converge stops being a trap for them, and a media module on another machine
@@ -60,10 +72,10 @@ services get an owner, converge stops being a trap for them, and a media module
 
 ## Open questions for the decision
 
-- The seat's name and whether Samba and NFS are one seat with two protocols (ADR 0129: a seat
-  carries the protocol of its role) or two seats.
 - Whether an NFS export over the overlay is an `internal` reach of the same endpoint or a second
   export line — NFS authorises by client address, so the mesh range and the LAN range are two
   entries in one file.
 - How a consumer's binding expresses a *path* to mount (today bindings carry `at`, `port`, `as` and
-  whatever the provider `serves`).
+  whatever the provider `serves`), and whether one share can serve several paths.
+- Whether the seat should exist before its first module (a system seat is a decision, ADR 0110) —
+  the decision that adds the two seats can be the one that accepts this proposal.