docs: v0.130.0 — CHANGELOG + README export section + REUSE (2 helpers) + CONTEXT + REPORT

CHANGELOG.md

@@ -1,5 +1,50 @@
 ## Changelog
 
+### v0.130.0 — CRITICAL C6B-F1: hollow .fab export (three compounding defects) + C6B-F2 share-removal guard (2026-07-14)
+
+CAMPAIGN-6B surfaced that `.fab` export produced a **config-only, data-free bundle** for 12/13
+`needs_hdd` catalog apps, reported success, and passed the v0.125.0 anti-hollow guard (live: sonarr,
+4.17 GB / 7 files → a 2308-byte bundle). Cross-box/fresh restore = silent total data loss. The
+scheduled/tier-2 backup path was NOT affected (it copies the felhom-data namespace wholesale) and is
+untouched. Controller-only.
+
+- **C6B-F1 cause 2 (discovery, `cmd/controller/main.go` exportAdapter + new `stacks.ExportDataMounts`):**
+  the export adapter resolved only `${HDD_PATH}` binds (`ParseComposeHDDMounts`), never the standard
+  `${USERDATA_PATH}` convention (`<HDD_PATH>/userdata`, injected at deploy) → 0 mounts → "no HDD
+  mounts — skipping". Fix: `stacks.ExportDataMounts` unions the HDD binds with the **userdata ROOT**
+  (one mount, basename `userdata`) when the compose binds `${USERDATA_PATH}`. Root-not-per-bind is
+  deliberate: the manifest keys HDD tars by basename and the import maps a basename to a resolved
+  mount or `<HDD_PATH>/<basename>` — `userdata` round-trips through the UNTOUCHED import exactly,
+  while a per-bind `userdata/media/tv` would base to `tv` and restore to the wrong place (the task's
+  literal per-bind union + namespaced tar names would have required import changes, which the task
+  forbade — deviation documented in REPORT). Containment dedupe both directions. The backup-side
+  `stackAdapter` is intentionally unchanged. Also fixes the estimate's `data=0 B` for these apps.
+- **C6B-F1 cause 1 (either/or, `appexport/export.go` executeExport):** `needs_hdd` apps never ran
+  `exportVolumeData`, silently dropping named volumes (sonarr_config = the whole app DB). Export is
+  now ADDITIVE (HDD data AND volumes); `EstimateExport` counts both so fits-on-dest stays honest.
+- **C6B-F1 cause 3 (guard, `appexport/export.go` assertBundleDataComplete):** the claimed-tar checks
+  pass trivially on 0 claims. New assertion: a `needs_hdd` manifest with neither HDD data nor volume
+  data fails the job ("a mentés nem tartalmaz alkalmazásadatot…") — a future discovery gap can never
+  again ship a silent hollow bundle.
+- **§8 latent collision (`appexport/export.go` exportHDDData):** two mounts sharing a basename used
+  to silently overwrite the first tar; now a loud Hungarian failure (basename-keyed manifests cannot
+  round-trip a collision; renaming would break the import mapping). `exportHDDData` returns error.
+- **C6B-F2 (share-removal guard, `web/netstorage_handlers.go`):** `POST /api/storage/netstorage/remove`
+  now refuses (409, names the apps) while a DEPLOYED stack's HDD_PATH is on the share — the live
+  event removed campaign6 under a running sonarr and the agent's tolerated stop steps deleted the
+  unit files under the busy mount, leaving an unreapable orphaned autofs mount until host reboot.
+  The remove handler resolves the agent via the netAgent seam. **Residual (out of scope, flagged for
+  a felhom-agent task):** the agent-side tolerate-and-continue stop in `RemoveNetworkMount`.
+
+Tests (non-hollow, four red-proofs run→fail→revert): `stacks/export_mounts_test.go` (6 — union,
+HDD-direct regression, mixed, covering-root, literal-userdata dedupe, empty; red-proof: pre-fix
+HDD-only behavior fails 3), `appexport/export_additive_test.go` (5 — scenario A both-tars bundle,
+scenario E volume-strand fails loud for needs_hdd, §8 collision loud-fail, scenario A' round-trip
+placement to `<HDD_PATH>/userdata`, scenario D zero-data refusal; red-proofs: either/or revert fails
+A, collision-check removal fails the collision test, guard removal fails D),
+`web/netstorage_remove_guard_test.go` (2 — refused-while-deployed + proceeds-without; red-proof:
+disabled guard returns the live `removed:true`).
+
 ### v0.129.0 — CAMPAIGN-4 fixes: rate-limiter key (F-B) + volume-blind estimate (F-A) + no-op claim status (F-C) (2026-07-14)
 
 Three controller-side fixes from CAMPAIGN-4 (2026-07-13). Controller-only.