R-116 Part 5 FAILED: the fix shipped, C5 still fails, mechanism NOT isolated

A fresh box running the fully shipped stack -- agent 0.115.0 from the Day-0
manifest plus controller 0.185.1 from the vouched golden, no hand-deploy -- still
fired the GENERIC storage_disconnected on detach and the SPECIFIC
backup_target_restored on return. backup_target_absent count 0. Identical to
Session C. The v0.115.0 fix changed nothing observable.

Part 4's three positive observables were all obtained before the run (registry
newest 0.115.0, hub vouches 0.115.0, felhom-pve running 0.115.0 clean), so the
publish step forgotten twice was not forgotten a third time, and the box
demonstrably installed the fix under test.

Discrimination FAILS: the target itself produced the generic event, so the two
cannot be told apart regardless of the non-target leg -- which was therefore not
staged. Reported as a fail, not as Session C's trivial pass.

Over-correction guard PASSES: 0 ABSENT lines with the drive present, target
degraded:false.

THE HONEST PART. The fix targets a shape that does not occur live, and which
shape does occur is NOT ISOLATED. With the drive detached PVE reports the
storage inactive with zeroed fields -- a shape the unit fixture did not model.
Three attempts to read the real /disks payload failed on token extraction across
the ssh -> guest -> container layers, and a present-drive CONTROL query also
returned 0 rows, proving the query was broken rather than the payload. Without
that control this run would have recorded a third false mechanism, after "the
union row writes false" (wrong, corrected yesterday) and "no row carries the
guest path" (unverified). The leading hypothesis -- an inactive storage reaching
Observe with an empty MountPath, so StablePathForRaw returns "" -- is consistent
with the pvesm output but is NOT evidence and is recorded as such.

Next session's first job is a working /disks read, with a present-drive control
run FIRST, before any further code.

agent v0.115.0 is published, vouched and INERT. Not reverted: reverting is
itself a change, the runbook forbids fixing mid-run, and the code is tested and
harmless.

Capability-map row F stays PARTIAL, now citing the re-test.
Teardown clean: pvesm status after == before (local-lvm 38.83%), guest 9201 and
drill-r50 untouched. Customer sess-d pending the usual ONLINE-ages-to-DOWN gate.

documentation/architecture/00-capability-map.md

@@ -121,7 +121,7 @@
 
 | Scenario | Components | Status | Evidence | Gap / roadmap |
 |---|---|---|---|---|
-| An ABSENT backup-target drive raises its OWN alarm, paired with a matching recovery | agent v0.114.0, controller v0.184.1+, hub v0.81.0 | **PARTIAL** | `SESSION-C-2026-07-29` C5: the drive-absent gate fires (4 s) and an alarm reaches the hub — but it is the **generic** `storage_disconnected`, while the return fires the **specific** `backup_target_restored`, so the pair cannot be matched. `backup_target_absent` never fired (count 0) | The specific alarm and its severity, Hungarian copy and hub routing are all still unexercised end-to-end → **R-116** |
+| An ABSENT backup-target drive raises its OWN alarm, paired with a matching recovery | agent v0.114.0, controller v0.184.1+, hub v0.81.0 | **PARTIAL** | `SESSION-C-2026-07-29` C5: the drive-absent gate fires (4 s) and an alarm reaches the hub — but it is the **generic** `storage_disconnected`, while the return fires the **specific** `backup_target_restored`, so the pair cannot be matched. `backup_target_absent` never fired (count 0) | RE-TESTED 2026-07-30 on the fully shipped stack (`R116-PART5-2026-07-30`) — **still generic**; the v0.115.0 fix was ineffective and the mechanism is not isolated. The specific alarm, its severity, Hungarian copy and hub routing remain unexercised end-to-end → **R-116** |
 | Health-degradation email (edge-triggered, cooldowns, Hungarian) via hub → Resend | controller, hub | **IMPLEMENTED** | delivery pipeline live-proven for the **enlarge-block** trigger (`CAMPAIGN-6D` P3-DELIVERY, op+customer "Kedves Ügyfél!"); `NotifyHealthChange` ok→warn/fail edge-trigger implemented | The **health-degradation** trigger specifically has never fired an email live in any doc. Demoted (pipeline proven for a different event). Deliverability to HU freemail → R-4 |
 | Event catalog: app_start_failed, dead-app, offbox_enlarge_blocked, claim/reset codes, critical severity | controller, hub v0.31/48/50/55 | **PROVEN-LIVE** | live-delivered: `CAMPAIGN-6D` P3-DELIVERY (enlarge-block, op+customer); `DRILL-day0-vm` F-4 (claim code); `DRILL-day0-take2` F-15 (reset code) | `app_start_failed`/`dead-app` delivery is unit-only (6C inconclusive) — the pipeline + 3 event families are live, those two are not |
 | Prefs safety: empty-email wipe guard | controller v0.137 + hub v0.71.0 | **IMPLEMENTED** | controller leg red-proofed 07-15; hub-side no-clobber belt (`handleSavePreferences` preserves a stored non-empty address on an empty-email push) red-proofed 07-22 | Born from a live incident; controller 0.160.0 guards both its push legs, so the hub belt covers older/rogue boxes |