fix(node): how a hosted group admits people is the operator's, not the hub's

attach_group no longer copies join_policy and visibility from the hub's
answer: they come with the operator's request (the desktop creation form,
`group add --open`) and default to invite/private; the CLI says when the hub
lists the group otherwise. Every string written into node.toml is escaped
(toml_string) and read back through tomllib, so a group or folder name cannot
write lines of its own (F-17).

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

1 files changed, 6 insertions, 0 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 2966e5e..38977af 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -544,6 +544,12 @@ admission. Only the second decides whether a code is required: a public group wi
 
 **`join_policy` is read from `node.toml`, never from the hub.** A hub able to
 declare a group open would be handed its key. An unknown group reads as `invite`.
+It is written there when the node starts hosting the group, from the operator's
+own request — the creation form in the desktop application, `group add --open` on
+the command line — and is `invite` unless that request says `open`; the hub's
+record of the group is looked up for its id and name only. Every string written
+into `node.toml` is escaped as a TOML string (`ops.node_toml.toml_string`): a group
+or folder name is someone else's text.
 
 ### 3.6 Passphrase change and recovery