feat(D53): the hub learns which apps are held — app_held / app_hold_cleared, daily repeat

internal/holdreport: one observer of the hold store, ticked every minute; app_held for a new or changed
hold (stack_name, reason, since, why), app_hold_cleared when gone (also while the controller was down:
settings.reported_holds), every hold again daily and at start. Severity info. RestoreHold.Why/WireReason
(holdWhy calls it). 8 tests, red-proved (inert Tick; unwired scheduler line). Commit only (felhom.eu 08 §10).

controller/README.md

@@ -2283,6 +2283,10 @@ that folder is never a dead end, and an install never runs into it silently (R-6
 - **R-1286 (v0.344.0).** A held app says WHY: each hold reason (a failed restore, an unhealthy stop by the crash-loop
   guard, …) has its own sentence in the start gate, the boot sweep and `--restore-holds` (an unhealthy stop used to
   read as a failed restore).
+- **D53 (next release, felhom.eu `08` §10).** The hub learns which apps are held: `internal/holdreport` reads the hold
+  store every minute and sends `app_held` (stack, reason, since, the hold's sentence) for a new or changed hold and
+  `app_hold_cleared` when one is gone — also one cleared while the controller was down (`settings.reported_holds`) — and
+  repeats every hold daily and at start. Both are severity info; the hub's operator reminder after a grace is the mail.
 - **R-690 (fixed here).** The removed-app restore (R-487) never found a unit on a DATA drive — it asked
   `GetStackComposePath`, true for every catalog app — and restored with no env. It now asks `isStackDeployed`.
 - `.felhom.yml` **`after_load: {service, user, command: [...]}`** — one command run with `docker compose exec -T`