The tool runner reads the memberships state again until it can, instead of giving a module up at its one follow

A JetStream 503 or a timeout at the follow (a bus right after its boot) left the module with no membership for good, since
Follow runs once per module and the stream fallback is gone. The read is now tried again with a growing wait (1 s doubling
to 30 s) until it watches the key or the connection closes; the failure is said once, and its reading once it succeeds.
Tests: none added; a step added to an existing unit test (TestAModuleHearsEveryStreamItsMembershipNames), which fails
without the retry.

(issue 774, 774/S32, review g1 round 1)
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL

node-tools/internal/meshtest/meshtest.go

@@ -131,6 +131,14 @@ func (m *Mesh) putGrants(t *testing.T, mem bus.Membership, body []byte) {
 	}
 }
 
+// DropGrants deletes the grants part's state memberships, as a bus that has not made it yet holds none; Issue makes it again.
+func (m *Mesh) DropGrants(t *testing.T) {
+	t.Helper()
+	if err := m.js.DeleteKeyValue(buscompose.GrantsMembershipsBucket); err != nil {
+		t.Fatal(err)
+	}
+}
+
 // sdkMembership is a membership of this package's type as mesh-sdk's, which the grants part composes and writes.
 func sdkMembership(t *testing.T, mem bus.Membership) membership.Membership {
 	t.Helper()