hub v0.89.0 — the two halves of decision D-c (R-167, R-158)

New OPERATOR-ONLY event type recovery_unit_capture_failed (controller
v0.191.0, R-158): in allowedEventTypes AND notify.operatorOnlyEvents.
Deliberately not a reuse of backup_failed, which carries customer copy and
sits in the controller's DefaultEnabledEvents — reusing it would email the
customer in Hungarian about a failure they cannot act on. R-158's own
proposal said backup_failed; D-c overrides it.

disk_warning/disk_critical lose their generic customerMessages entries.
Both were allowlisted, copy'd, default-enabled and checkbox'd with NO
producer anywhere; controller v0.191.0 becomes that producer and sends a
DYNAMIC Hungarian message naming the drive and its free space.
FormatCustomerEmail prefers the entry over the message, so keeping a static
entry would discard the label and the byte figures — the same reason
offbox_enlarge_blocked and disk_health_degraded have none. The deletion is
pinned by a test.

New notify.IsOperatorOnly so the api package can pin BOTH registers of a new
event type in ONE test; allowlisted-but-not-operator-only is invisible when
they are checked separately, and it is the defect v0.78.0 shipped. The
register itself stays unexported.

REUSE.md's "new event type" extension point rewritten: it told readers to
always add a customerMessages entry, which is wrong for operator-only types
and harmful for dynamic-message ones.

Tests 574 -> 579. Red-proof: removing the operatorOnlyEvents entry shows the
customer being emailed; the skipped/operator_only row is asserted as a
positive observable.

hub/CHANGELOG.md

@@ -1,3 +1,36 @@
+## v0.89.0 — the two halves of decision D-c (2026-08-02, R-167 · R-158)
+
+**Decision D-c routes two new signals to two different audiences, and the hub is where that routing
+is enforced.** A customer can free space, delete files or add a drive, so a FILL WARNING is theirs. A
+customer can do nothing about a per-app backup capture failure, so it is not.
+
+**New operator-only event type `recovery_unit_capture_failed`** (controller v0.191.0, R-158). Added to
+`allowedEventTypes` **and** to `notify.operatorOnlyEvents`. Deliberately NOT a reuse of
+`backup_failed`, which carries a `customerMessages` entry and sits in the controller's
+`DefaultEnabledEvents` — reusing it would email the customer, in Hungarian, about a failure they
+cannot act on. R-158's original proposal named `backup_failed`; D-c overrides it.
+
+**`disk_warning` / `disk_critical` lose their generic `customerMessages` entries.** These two types
+were allowlisted here, carried Hungarian copy, sat in the controller's default enabled events and had
+a UI checkbox — and **nothing in any repo emitted them**, a complete customer pipeline with no
+producer. Controller v0.191.0 becomes that producer, and it sends a **dynamic** Hungarian message
+naming the drive and its free space. A static entry would be actively harmful: `FormatCustomerEmail`
+PREFERS the entry over the message, so keeping one would discard the label and the byte figures and
+leave the customer with *"A lemezterület 90% felett van"* — a warning with nothing to act on. Same
+reason `offbox_enlarge_blocked` and `disk_health_degraded` have no entry. The deletion itself is
+pinned by a test.
+
+**New `notify.IsOperatorOnly`** — a read-only accessor so the `api` package can pin BOTH registers of
+a new event type in ONE test. Allowlisted-but-not-operator-only is invisible when the two are checked
+separately, and it is the defect v0.78.0 actually shipped. The register stays unexported so nothing
+can widen it at runtime.
+
+**Tests:** 574 → **579**. The operator half is proven through the real dispatch path under the
+*breaking* configuration — the customer has the event enabled and has an email address — because that
+is the only configuration in which a missing `operatorOnlyEvents` entry is visible. Red-proof:
+removing the entry shows the customer being emailed, and the `skipped/operator_only` log row is
+asserted as a positive observable rather than inferred from an absent delivery.
+
 ## v0.88.0 — the WAL that never was (2026-08-02, R-172)
 
 **The hub has never actually been in WAL mode.** `store.New` opened the database with