feat(node): the operator can close uploading to everyone but themselves

A group where every member may add files stays the default. Some groups want a
library the operator curates, and until now the only way to get one was to
designate no upload root at all — which refuses the operator too.

**The node enforces it; the interface merely stops offering it.** The Upload
button in the Files toolbar and the paperclip in the chat composer both
disappear, which is a courtesy to the people who are not trying. The control is
`_do_file_upload` refusing with `member_upload_off`, so a member on an old tab,
or one speaking MNP directly, gets the same answer. There is a test for each,
and the enforcement test is in the node package rather than beside the UI one so
nobody reads the hidden button as the mechanism.

**Changing it is a signed operator instruction** — `OP_MEMBER_UPLOAD`, on the
same path as removing a member. An unsigned one would let any member turn it
back on and make the setting a suggestion. The transcript's subject is `on` or
`off`: what the operator is shown before signing has to name the outcome, not
the operation.

**It lives on the node**, in a new `group_settings` table in `roster.db`. Not
the hub, which has no business deciding who may write to someone else's disk.
Not `node.toml` either: that file is hand-written and full of comments recording
decisions, `ops.py` appends to it rather than round-tripping it through a
writer, and a setting toggled from a panel must not rewrite the operator's file
or need a restart. The value is cached in the group context because the upload
path is synchronous, and the signed operation updates both — storing it without
applying it would make the panel say one thing while the node did another.

**Absent means allowed**, at every layer: no row in the table, no key in the
context, no field in `handshake_ack`. An older node and an older client both
behave exactly as before, and upgrading never silently closes a group. Each of
those three has its own test, because they fail independently.

The operator is always exempt — otherwise turning it off locks them out of their
own node with a config file and a restart as the only way back. `is_node_admin`
was being computed in two places by then and is now one function, since two
copies of "is this the operator" is how the ack and the gate come to disagree.

A change reaches everyone already connected via `member_upload_ack`, so the
button goes without a reconnection. That message is both a broadcast and the
reply to the request that caused it, which is why the client does not return
early on it.

Docs updated for a cold start: draft-v6 §2.1b and change 9, a new "Where Phase
13 stands" section in CLAUDE.md recording what is built, deployed and still
missing, the module map row, and desktop-client-v1 §10b on the Settings tab and
where group settings live.

883 tests pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2 files changed, 51 insertions, 0 deletions

diff --git a/docs/desktop-client-v1.md b/docs/desktop-client-v1.md
index c0bbb90..08dd548 100644
--- a/docs/desktop-client-v1.md
+++ b/docs/desktop-client-v1.md
@@ -1091,6 +1091,23 @@ Deletions enabled once native is the recommended client are unchanged from
 
 ---
 
+## 10b. Group settings, and where they live
+
+The group tab that was "Members" is **"Settings"**, and it is where anything about the
+group is administered: invitations, operator pairing, your devices on this node, whether
+members may upload, leaving or deleting the group, and the roster — last, because it is
+the only part with no upper bound.
+
+Two rules came out of building it and both are easy to undo by accident:
+
+- **The tab bar does not wait for the node.** Membership is hub-side. Gating the tab on a
+  live connection makes "leave this group" unreachable exactly when a node is down, which
+  is when someone most wants it. Sections that do need the node say so.
+- **A setting that governs the node is stored on the node and enforced by the node.**
+  `member_upload` is the worked example: signed operator instruction, row in `roster.db`,
+  refusal in `_do_file_upload`. Hiding the Upload button and the chat paperclip is a
+  courtesy to people who are not trying; it is not the control. See draft-v6 §2.1b.
+
 ## 11. Open items, each needing its own review
 
 | # | Item | Why it is not decided here |
diff --git a/docs/meshbay-draft-v6.md b/docs/meshbay-draft-v6.md
index 6a161cd..2ea73c4 100644
--- a/docs/meshbay-draft-v6.md
+++ b/docs/meshbay-draft-v6.md
@@ -42,6 +42,7 @@
 | 6 | Portability | exFAT/NTFS and Windows are the **common** case. Case folding and Unicode normalization become correctness requirements, not compatibility notes | E8 / decision 12 |
 | 7 | Accounts | Native registration is **hybrid**: passphrase-derived `auth_key` (the recovery path) plus a device Ed25519 key for day-to-day authentication | E3 / decision 4 |
 | 8 | Authorship | Chat senders are **cryptographically authenticated to each other**; an upload has a **provable owner** who may delete it, as the operator may. v5's node-asserted attribution is replaced | operator decision, §2.4b |
+| 9 | Node authority | The operator may **close uploading to everyone but themselves**, per group. Signed MNP op, stored on the node, enforced by the node — the hidden button is a courtesy, the refusal is the control | §2.1b |
 
 ---
 
@@ -67,6 +68,39 @@ v5's rule that nothing derived is written beside the originals is **unchanged**,
 decides the video-thumbnail question: a frame grab is produced on demand and cached on the
 device that asked, so the node keeps no thumbnail store.
 
+### 2.1b §5.2 Uploads — the operator may close them
+
+New. A group where every member may add files is the default and stays the default;
+some groups want a library the operator curates, and until now the only way to get one
+was to designate no upload root at all, which refuses the operator too.
+
+`member_upload` is a per-group setting, and three things about it are load-bearing:
+
+- **It lives on the node**, in `roster.db`, not in `node.toml` and not on the hub. Not
+  the hub because a hub that decides who may write to someone else's disk has authority
+  over that node, which is the arrangement this design exists to avoid (change 5). Not
+  `node.toml` because that file is hand-written, full of comments recording decisions,
+  and `ops.py` deliberately appends to it rather than round-tripping it through a
+  writer — a setting changed from a panel must not rewrite the operator's file, and must
+  not need a restart.
+- **Changing it is a signed operator instruction** (`OP_MEMBER_UPLOAD`, MNP
+  `member_upload`), on the same path as removing a member. An unsigned one would let any
+  member turn it back on, which makes the control a suggestion. The transcript's subject
+  is `on` or `off` — what the operator is shown before signing has to name the outcome,
+  not the operation.
+- **The node enforces it**; the interface merely stops offering it. `handshake_ack`
+  carries `member_upload` so a client knows whether to draw the Upload button and the
+  chat paperclip, and the node broadcasts `member_upload_ack` to everyone connected when
+  it changes. None of that is the control: a member on an old tab, or one speaking MNP
+  directly, is refused by the node with `member_upload_off`.
+
+**Absent means allowed**, at every layer — no row in `group_settings`, no key in the
+group context, no field in the ack. A node or client that predates the setting behaves
+exactly as it did, and an upgrade never silently closes a group.
+
+The operator is always exempt. Turning it off otherwise locks them out of their own
+node, with a config file and a restart as the only way back.
+
 ### 2.2 §5.5 Admission — devices, not one key per person
 
 v5 and `invite-pairing-v1.md` bind **one** key pair to an account per node: `identities`