feat: a group can be left out of Search, and Search tries every node

`search_listed` is a per-group setting on the node, changed by a signed
operator op and carried in the sealed handshake ack. Search reads it after
the handshake and stops there: no index is fetched, cached or merged, in any
of the four views, and the page says how many groups it left out. The switch
is a "Search" section in the group's settings, shown to the operator.

Absent means listed, at every layer: roster default, ack default, and the
client only drops a group on an explicit `false` — so an upgrade or an older
node removes nothing from anyone's Search.

It is a listing preference and protects nothing: the node serves the same
index to Search and to the group page and cannot tell them apart, every
member lists the group by opening it, and a client that ignores the flag
lists it in Search too. Design §9.11 says so, so it is never described as
private. The cost is one handshake per unlisted group, because only the node
knows the setting.

Search also took `nodes[0]` twice — for the index and for the pooled
connection — the defect 4cce50f fixed on the group page only. One
`connectToGroup` now walks the list the same way: a refusal about this
browser stops, `not_hosted` or a failed connection moves on.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XuNrwLf5EFWCMHzfoEvnpm

2 files changed, 17 insertions, 0 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 86b8e8f..6053bd8 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -2348,6 +2348,20 @@ Two rules for a new application here:
 group is a top-level folder, and merging would remove a file from one of them. A
 test refuses a build that changes this.
 
+**A group can be left out of Search** — `search_listed`, a per-group setting on the
+node, signed by the operator and carried in the sealed ack. Search reads it after the
+handshake and stops there: no index is asked for, cached or merged, in any of the four
+views. The case it exists for is a family album that should not turn up in the middle
+of a film library.
+
+> **It is a listing preference and it protects nothing, against anyone.** The node
+> cannot tell Search's request from the group page's and serves the same index to
+> both; every member lists the whole group by opening it; a client that ignores the
+> flag lists the group in Search too. It must never be described as "private" or
+> "confidential". What it costs is one handshake per unlisted group, because only the
+> node knows the setting — a hub-side flag would save that and put group state on the
+> hub (§1.3).
+
 One consequence is deliberate and is not a bug: albums are keyed by directory, so
 two groups whose roots have *different* basenames put the same photo into two
 differently-named albums, and the merge — scoped to a unit — leaves it in both. They
diff --git a/docs/MESHBAY_NODE_PROTOCOL.md b/docs/MESHBAY_NODE_PROTOCOL.md
index 81605c6..f3fcbb9 100644
--- a/docs/MESHBAY_NODE_PROTOCOL.md
+++ b/docs/MESHBAY_NODE_PROTOCOL.md
@@ -532,6 +532,7 @@ at all — including a decryption.
 | `<app>_directories` | each application's entry-point folders, keyed by the app's own registry name (`video`, `music`, `photo`, `chat`), **always a list**. This is the only form. The scalar `video_root` / `audio_root` / `photo_roots` fields that used to sit beside it are gone: one folder was never the general case, and two shapes for one answer meant whichever the reader consulted first decided it |
 | `chat_directory` | where chat attachments are written. Singular because Chat genuinely has one destination; `""` means the operator has not chosen |
 | `chat_link_preview` | whether the node unfurls links posted here. Absent means on |
+| `search_listed` | whether the reader's cross-group Search lists this group. Presentation only — the index is served identically either way. Absent means listed |
 | `chat_epoch` | the chat epoch a client must seal under right now (§11.7). There is no `chat_encrypted` beside it, because there is no switch |
 | `transfer_limits` | `{download, upload}` — this member's own caps in this group, so the interface can say "2 of your 2 slots are busy" instead of drawing a bare spinner. Absent reads as "no limit known" and the hint is not drawn; never as "unlimited", which would have the interface contradicting the node (§11.2) |
 | `tmdb_enabled`, `musicbrainz_enabled` | per-group metadata lookups |
@@ -1000,6 +1001,7 @@ broadcast, every connected peer in the group learns the change without reconnect
 | `app_directories` | `<app>:<dir>,<dir>,...` | operator | `app_directories_ack{app, dirs}` | yes |
 | `chat_directory` | the path | operator | `chat_directory_ack{path}` | yes |
 | `chat_link_preview` | `on\|off` | operator | `chat_link_preview_ack{enabled}` | yes |
+| `search_listed` | `on\|off` | operator | `search_listed_ack{listed}` | yes |
 | `transfer_limits` | `d=<n>,u=<n>` | operator | `transfer_limits_ack{limits}` | yes |
 | `chat_epoch` | `group_id` | operator | `chat_epoch_ack{epoch}` | yes |
 | `group_attach`, `group_detach` | `group_id` | operator | `group_attach_ack` / `group_detach_ack` | no |
@@ -1879,6 +1881,7 @@ it back (§3.5).
 | `app_directories` / `_ack` | C→N / N⇒C | signed | one application's folders, keyed by app name |
 | `chat_directory` / `_ack` | C→N / N⇒C | signed | where chat attachments are written |
 | `chat_link_preview` / `_ack` | C→N / N⇒C | signed | whether the node unfurls posted links |
+| `search_listed` / `_ack` | C→N / N⇒C | signed | whether members' cross-group Search lists this group |
 | `root_update` / `_ack` | C→N / N⇒C | signed | a root's `writable` / `removable` flags |
 | `root_eject` / `_ack`, `root_plug` / `_ack` | C→N / N⇒C | signed | take a removable root offline, put it back |
 | `gek_rotate` / `_ack` | C→N / N→C | signed | node generates a new group key |