v0.123.0: a tier the box cannot READ now says so (R-185)

The missing grant is one command; the silence was the defect. On demo-felhom the
agent's token has FelhomAgentStore on local, local-lvm and felhom-pbs — and not
on felhom-backup, the storage the same installer configured as
local_backup_target. That storage answers {"data":[]} through the token while
root sees three archives.

An empty listing is what a FORBIDDEN tier and a NEWBORN tier both return, so
pickForThisRun skipped it as "no settled archive yet" and the tier was never
restore-testable on that box. The permission question, unlike the listing, has a
definite answer, so it is asked directly: Client.Permissions reads
/access/permissions as the agent's OWN token, and one capability.Status per
configured tier reports it — composed around the sudo prober, the way the
pool-read check already is.

Measured first, because the obvious reading is wrong: an ungranted path answers
neither empty nor 403, but with the privileges inherited from the box-wide grant
(Sys.Audit, SDN.Use, Datastore.Audit). Checking for Datastore.Audit would report
a blinded storage healthy — red-proved. The probe tests for
Datastore.AllocateSpace.

The probed set comes from the box's own config, never a fixed list: a hardcoded
probe list is the defect reproduced inside the fix. Critical, because the hub
alerts only on critical — except the "local" fallback target, which is reported
but does not page. It never looks at content, so it cannot alarm on a newborn
tier; it never reports ok when it could not ask. Status wire shape unchanged, so
no hub change.

CHANGELOG.md

@@ -1,3 +1,51 @@
+## v0.123.0 — a tier the box cannot READ now says so (2026-08-03, R-185)
+
+**The missing permission is one command. The silence was the defect.** On demo-felhom the agent's PVE
+token held `FelhomAgentStore` on `local`, `local-lvm` and `felhom-pbs` — and **not** on
+`felhom-backup`, the storage the same installer had configured as `local_backup_target`. Asked for
+that storage's content the API answers `{"data":[]}` while root sees three archives (6.1–6.3 GB,
+08-01/02/03).
+
+**An empty listing is what a FORBIDDEN tier and a NEWBORN tier both return.** `pickForThisRun` skips
+an empty tier — correctly, because a fresh offsite tier legitimately has nothing yet — and reports
+*"no settled archive yet"*. So that tier was never restore-testable on that box and nothing ever
+mentioned it. This project's own rule, in a new place: an empty answer is not evidence that there is
+nothing there.
+
+**The permission question, unlike the listing, has a definite answer — so it is asked directly.**
+`Client.Permissions` reads `GET /access/permissions?path=/storage/<target>` **as the agent's own
+token** (asking as root answers a different question and always says yes), and one
+`capability.Status` per configured tier reports the result. It composes *around* the sudo prober, the
+way the pool-read check already does — an API read does not belong inside a sudo-policy probe.
+
+**MEASURED FIRST, and the obvious reading is wrong.** The ungranted path does not answer empty and
+does not 403:
+
+```
+/storage/felhom-pbs     → {"Datastore.Allocate":1,"Datastore.AllocateSpace":1}
+/storage/felhom-backup  → {"Sys.Audit":1,"SDN.Use":1,"Datastore.Audit":1}
+```
+
+It answers with the privileges **inherited** from the box-wide `/` grant. A probe asking *"is the
+path present?"* or *"does it have `Datastore.Audit`?"* would report the blinded storage healthy — so
+the probe tests for `Datastore.AllocateSpace` specifically, and a red-proof pins that.
+
+**Decisions, each weighed once:**
+
+- **The probed set comes from the box's own config** (`BackupTiers()`), not a fixed list. A hardcoded
+  probe list is exactly the defect being fixed, reproduced inside the fix.
+- **CRITICAL**, because the hub alerts only on critical and a non-critical entry would ride the
+  report and alert nobody — the same silence with extra steps. **Except** the `local` fallback
+  target, which host-install's own comment calls the DEGRADED configuration: it is still probed and
+  still reported, but it does not page, because turning an ordinary documented setup into an alert
+  is how a signal becomes something an operator archives unread.
+- **It never looks at content**, so it cannot alarm on a newborn tier by construction.
+- **It never reports ok when it could not ask.** An unreachable PVE is degraded: a self-check that
+  fails open converts *"I do not know"* into *"fine"*.
+
+The wire shape (`capability.Status`) is unchanged, so the hub's existing critical-degraded alert
+applies with no hub change and no hub bump.
+
 ## v0.122.0 — three ways the signals lied about themselves (2026-08-03, R-189 · R-188 · R-186)
 
 All three are the reporting and release path misreporting its own work. **No customer machine, no