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

1 files changed, 14 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