deploy, docs: turn service_down back on (V-444)

It was disabled because it could not say which service. It can now.

docs/design.md

@@ -389,6 +389,29 @@ lives in `source`; rules trust provenance.
   `source=poll:healthcheck`. A compromised poller must not be able to forge a
   trigger.
 
+#### A fact per monitor, not an aggregate
+
+mavpoll writes one fact per kuma monitor, keyed `service_down:<monitor name>`.
+It used to fold the whole gauge into a single boolean, and the nudge could then
+only say that something on homesrv was down. That is not something he can act
+on, so the rule shipped disabled.
+
+Three things follow from the split:
+
+- The key set is no longer known at wiring time. A rule declares
+  `WantPrefixes` and the gatherer resolves the family per tick, which is the
+  only prefix read in the loop.
+- Pausing a monitor in kuma silences that monitor. Under the aggregate it
+  silenced nothing, because some other monitor kept the boolean at "down".
+- A monitor deleted in kuma would keep its last fact reading "down" forever, so
+  mavpoll marks a vanished monitor "unknown". No rule fires on "unknown".
+
+The rule is also edge-triggered: it fires on a transition it has not already
+nudged about (`State.NudgedSince`). A polled fact is written only when the
+value changes, but the predicate reads the current value, so without the edge
+check a service that stays down qualifies on every tick and cooldown is the
+only brake.
+
 ### Presence — concrete scoring
 
 **Combiner — noisy-OR, not weighted sum.** These are independent-ish positive