hub v0.90.0 — a dropped notification leaves a trace, and the backup digest arrives (R-182)

processOperator's cooldown no longer returns bare. It dropped the event BEFORE
LogNotification, so a suppressed operator alert and an event that never happened
were indistinguishable — from the operator's side and from the hub's own records.
Measured 2026-08-03: nine recovery_unit_capture_failed events arrived, two were
mailed, seven left no row anywhere. That is why the defect took a day to get the
right way round: there was nothing to read.

A suppressed operator event now writes a `suppressed` row carrying the message
and the key that suppressed it. This applies to EVERY operator event, not only
the one that exposed it. It does NOT change the cooldown's duration or semantics.

backup_run_failures: the per-run digest. In allowedEventTypes AND in
operatorOnlyEvents — allowlisting alone does not make an event operator-only,
and FormatCustomerEmail falls back to the raw English message rather than
blocking. A test demonstrates a customer with the type enabled receiving nothing.

recordOnlyEvents: a third routing class — stored and recorded, never mailed.
recovery_unit_capture_failed moves here: it is the record, the digest is the
notification. A register rather than downgrading severity to info, which would
relabel a genuine failure as informational everywhere it is queried.

cooldownRunSuffix: a sibling of cooldownTierSuffix, not a branch inside it, so
tier keeps byte-identical semantics and R-97a's tests are untouched. It makes
the cooldown effectively inert for the digest, which is the intent — a digest is
already rate-limited by construction; the refresh sweep sends no run_id and so
stays under the ordinary hourly cooldown.

The email renders as a list, not a JSON blob. An absent space reading renders as
unavailable, never as zeros.

hub/internal/notify/dispatcher.go

@@ -116,6 +116,18 @@ func (d *Dispatcher) ProcessEvent(customerID, eventType, severity, message, deta
 		return
 	}
 
+	// R-182: record-only types are written down and never mailed. Placed BEFORE the severity gate
+	// so the row is written whatever the severity — the record must not inherit the notification's
+	// conditions, which is the coupling this whole finding is about.
+	if recordOnlyEvents[eventType] {
+		if err := d.store.LogNotification(customerID, eventType, severity, message, "recorded",
+			"record-only: the per-run digest (backup_run_failures) carries the notification", "operator"); err != nil {
+			d.logger.Printf("[WARN] Failed to record %s for %s: %v", eventType, customerID, err)
+		}
+		d.logger.Printf("[INFO] Recorded (not mailed) %s for %s — the run digest is the notification", eventType, customerID)
+		return
+	}
+
 	// warning / error / critical trigger notifications. "info" is an intentional non-notify (status/
 	// recovery events). Anything else is UNRECOGNIZED — log it (don't silently drop), so a bad severity
 	// surfaces instead of vanishing (the felhom-pve-class lesson: a critical event must never be lost).
@@ -260,15 +272,67 @@ func cooldownTierSuffix(detailsJSON string) string {
 	return ":" + d.Tier
 }
 
+// cooldownRunSuffix returns ":"+run_id when the event's details carry a non-empty `run_id`, else "".
+//
+// R-182. `cooldownTierSuffix`'s sibling, and deliberately a SEPARATE function rather than an extra
+// branch inside it: `tier` keeps byte-identical semantics for every type that uses it, so R-97a's
+// behaviour and its tests are untouched by this.
+//
+// WHY A BACKUP RUN NEEDS ONE. The run digest describes ONE RUN, and a box can have two in a day —
+// the nightly one and a manual one the operator triggered *because* something looked wrong. With no
+// run-scoped discriminator the 1-hour cooldown would swallow the second, which is the failure this
+// row exists to fix, reappearing one level up: the operator presses the button, the run fails, and
+// they are told nothing because the machine already wrote that hour.
+//
+// IT MAKES THE COOLDOWN EFFECTIVELY INERT FOR THIS TYPE, AND THAT IS THE INTENT, NOT AN OVERSIGHT.
+// A digest is already rate-limited by construction — one per run, emitted only when something
+// failed — so there is nothing for a timer to collapse. The cooldown protects against a repeating
+// identical alert; a digest cannot repeat, because each run is a different run.
+//
+// NARROW, LIKE ITS SIBLING: empty unless the producer opts in by sending a `run_id`, so no existing
+// event type's cooldown behaviour changes.
+func cooldownRunSuffix(detailsJSON string) string {
+	if detailsJSON == "" || !strings.Contains(detailsJSON, "\"run_id\"") {
+		return ""
+	}
+	var d struct {
+		RunID string `json:"run_id"`
+	}
+	if err := json.Unmarshal([]byte(detailsJSON), &d); err != nil || d.RunID == "" {
+		return ""
+	}
+	return ":" + d.RunID
+}
+
 func (d *Dispatcher) processOperator(customerID, eventType, severity, message, detailsJSON, source string) {
 	if !d.operatorOn || d.operatorEmail == "" {
 		return
 	}
 
-	cooldownKey := customerID + ":" + eventType + cooldownTierSuffix(detailsJSON)
+	cooldownKey := customerID + ":" + eventType + cooldownTierSuffix(detailsJSON) + cooldownRunSuffix(detailsJSON)
 	d.mu.Lock()
 	if last, ok := d.opCooldowns[cooldownKey]; ok && time.Since(last) < 1*time.Hour {
 		d.mu.Unlock()
+		// R-182: RECORD THE SUPPRESSION. This used to be a bare `return` — the event was dropped
+		// before any LogNotification, so a cooldown drop and an event that never happened were
+		// indistinguishable from the operator's side AND from the hub's own records.
+		//
+		// Measured 2026-08-03: nine `recovery_unit_capture_failed` events arrived, two emails were
+		// sent, and the other seven left NO ROW ON ANY CHANNEL. The defect that hid was serious —
+		// the cooldown key carries no app identifier, so the first refused app took the slot and
+		// every other app's failure that hour was discarded — but the reason it took a day to find
+		// the right way round is this line: there was nothing to read.
+		//
+		// "We chose not to e-mail you" and "nothing happened" must never look identical. This
+		// applies to EVERY operator event, not only the one that exposed it. It makes the drop
+		// visible; it deliberately does NOT change the cooldown's duration or semantics.
+		if err := d.store.LogNotification(customerID, eventType, severity, message,
+			"suppressed", "operator cooldown 1h, key="+cooldownKey, "operator"); err != nil {
+			d.logger.Printf("[WARN] Failed to record suppressed operator notification for %s/%s: %v",
+				customerID, eventType, err)
+		}
+		d.logger.Printf("[INFO] Operator email suppressed for %s/%s — cooldown (key=%s)",
+			customerID, eventType, cooldownKey)
 		return
 	}
 	d.opCooldowns[cooldownKey] = time.Now()
@@ -285,6 +349,33 @@ func (d *Dispatcher) processOperator(customerID, eventType, severity, message, d
 	d.store.LogNotification(customerID, eventType, severity, message, "sent", "", "operator")
 }
 
+// recordOnlyEvents are STORED and RECORDED but never e-mailed, on either channel.
+//
+// R-182. The distinction this register exists to make is the whole of that finding: **the record and
+// the notification are different things.** A per-app backup failure must always be written down —
+// every time, unconditionally, regardless of cooldowns, preferences or whether any mail went out —
+// and it must NOT compete for an e-mail slot, because the per-run digest
+// (`backup_run_failures`) is what a person is meant to read.
+//
+// Before this, `recovery_unit_capture_failed` was both at once, and it did neither well: on
+// 2026-08-03 nine of them arrived, two were e-mailed, and the other seven were dropped by the
+// 1-hour cooldown BEFORE anything was written down. So the operator was told about one app, the
+// other apps' failures were discarded, and nothing anywhere recorded that a choice had been made.
+//
+// WHY A REGISTER AND NOT severity "info". Downgrading the severity would have the same routing
+// effect — `severityNotifies` drops info — but it would also relabel a genuine failure as
+// informational in the events table, the operator UI and every historical query, and it would
+// silently drop the X-Priority handling if the type were ever promoted back. This says what it
+// means: not silent, not urgent, RECORDED.
+//
+// IT IS NOT A WAY TO MUTE THINGS. A type belongs here only when something else carries its
+// notification. Adding one with no digest behind it rebuilds the silence R-182 was filed against.
+var recordOnlyEvents = map[string]bool{
+	// The per-app Tier-1 capture/refusal failure. Its notification is the run digest, which lists
+	// every failed app in one mail; this row is the durable per-failure record behind it.
+	"recovery_unit_capture_failed": true,
+}
+
 // operatorOnlyEvents are event types that must NEVER reach a customer, whatever their preferences say.
 //
 // R-97c. This register exists because the guarantee it provides was previously ASSERTED IN A COMMENT
@@ -321,6 +412,15 @@ var operatorOnlyEvents = map[string]bool{
 	// figures, the raw error). The customer's half of D-c is the FILL WARNING, which fires BEFORE
 	// this and is actionable: free space, delete files, add a drive.
 	"recovery_unit_capture_failed": true,
+	// R-182. The per-run backup digest. It is the same class as the line above and for the same
+	// reason — a customer can act on a full disk (that is the fill warning, which fires first and
+	// IS customer-facing) but not on a list of which apps' backups failed and why. It also carries
+	// operator-grade detail: per-app leg names, raw refusal reasons and byte figures.
+	//
+	// Listed here rather than relying on the absence of a `customerMessages` entry, which is NOT a
+	// block — `FormatCustomerEmail` falls back to the raw English message. That mistake shipped
+	// once (v0.78.0) and the comment above records it.
+	"backup_run_failures": true,
 }
 
 // IsOperatorOnly reports whether an event type is barred from customer dispatch. Exported so the