F-catalog-B: distribution's windows step by mesh-sdk's delivery.StepWindow and say why a node holds one

A read naming no node (an empty node_haves) closed both windows for good (security review F3, second of
a kind): the window embeds delivery.WindowHeld and steps by the shared rule, named being every node the
read named, and keeps its own guard that a window once closed stays closed. A node-engine whose
manifest-reads did not answer (a timeout included) counts as stating nothing as before, and the window's
record now says so per node (Why), so registry_old_name tells a timeout from an old node-engine. A read
that fails otherwise is an error the wake judges nothing on, no longer taken as not served.

Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig

modules/distribution/cmd/distribution/windows.go

@@ -91,9 +91,12 @@ func (d busDelivery) Reads(node string) (bool, []string, error) {
 	raw, err := d.c.CallOn(node, readsAsk, map[string]any{})
 	if err != nil {
 		if notServed(err) {
-			return false, nil, nil // a node-engine not serving manifest-reads states nothing (design 51)
+			// A node-engine not serving manifest-reads states nothing (design 51); what the call answered (an away node,
+			// an older node-engine, a timeout) goes with it, so the window's tool says why the node holds it.
+			return false, nil, err
 		}
-		return false, nil, err
+		// Any other failure is a read that did not happen: served true with its error, so the wake judges nothing.
+		return true, nil, err
 	}
 	var a struct {
 		Reads []string `json:"manifest-reads"`