docs(deploy): degraded-rebuild repair + node-side reason write (#601 review)

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

docs/Redundancy.md

@@ -616,7 +616,12 @@ deployment green fleet-wide. Now:
 - **Re-deploying a degraded revision repairs it.** The node's idempotent "already at this revision" short-
   circuit is skipped while the current revision's apply is degraded or its outcome is still pending — the
   dispatch re-applies instead, the publish actor re-diffs the un-advanced composition and re-ensures the
-  missing nodes, and the ack reports the new outcome.
+  missing nodes, and the ack reports the new outcome. A degraded **rebuild** is the other shape: it DOES
+  advance `_lastApplied`, so the identical re-deploy diffs to an empty plan — the publish actor remembers
+  that the last advance was degraded and, on that empty plan, re-ensures the whole composition (idempotent,
+  no second rebuild), reporting clean only if that pass is clean.
+- **A node with a ConfigDb also writes the reason on its own row** (`ApplyAck.DegradedReasonPrefix`), because
+  central only records it when it *accepts* the ack — a timed-out deployment's late ack is discarded.
 - **Mixed-version fleets.** An old node never sets the flag, so its acks are treated exactly as before
   (clean). A new node acking an old central: the old coordinator ignores the unknown field and seals as it
   always did — no worse than today.