v1.46.6: the detach promise, actually kept this time

v1.46.4 and v1.46.5 documented that detaching a plan leaves the image on disk,
added guards for it, and shipped tests. The guards were never reached: they sit
behind 'not superseded', and a file that left the configuration was called
superseded. From old_refs - new_refs alone, replacing a plan, detaching one and
deleting its space are indistinguishable — so all three deleted the file, at the
moment of the save, before any scheduled pass ever ran.

Every test I wrote for this called collect_plans(d, cfg, cfg): old config equal
to new, i.e. only the scheduled pass. The transition that mattered was never
exercised. Codex reproduced it in four lines.

Classification is by owner now:
  space in both, plan A -> plan B  : the user picked another image -> removed
  space in both, plan -> none      : detached -> kept
  space gone                       : kept (the image was imported; a thirty-day
                                     grace measured from file age is meaningless
                                     anyway, it was uploaded months ago)
  space has a plan, other file     : rejected upload -> 1 h
Attachments follow the same shape: dropped from a device that still exists ->
removed (a trash button promises nothing); device gone -> kept; staging folder
-> 1 h.

Tests: a matrix per rule in the pure module, and — the part that was missing —
test_detaching_a_plan_keeps_the_file, which goes through real config/set calls:
attach, detach, assert the file is there, restart, assert again, re-attach,
replace, assert the replaced one is gone, delete the space, assert the plan
survives. Also strengthened the sweep/save race test to assert the save actually
succeeded and the config points at the specific expected file, per the report.

docs/ARCHITECTURE.md

@@ -214,14 +214,22 @@ we should not have removed cannot be brought back.** When the evidence is weak,
 keep the file. Owner's decision, 2026-07-28, after the one-hour rule applied to
 every unreferenced file destroyed two detached plans.
 
+The classification is by **owner**, not by "is it referenced". A file leaving
+the configuration looks identical whether the plan was replaced, detached, or
+its space deleted — and only the first is a deletion the user asked for. Reading
+`old_refs - new_refs` and calling it "superseded" deleted a plan the moment it
+was detached, under documentation promising the opposite (HP-1465-01).
+
 | Case | What it means | Rule |
 |---|---|---|
-| In the old revision, not in the new | a save replaced it | removed immediately |
-| Space exists, has **no** plan | detached, one click to undo | **never removed** |
-| Space exists, has a plan | its own rejected upload | `PLAN_ORPHAN_TTL_S` (1 h) |
-| Space no longer exists | deliberate deletion, but people misclick | `SCHEDULED_GRACE_S` (30 d) |
-| Attachment in `up_*` | a dialog that was never saved | `PLAN_ORPHAN_TTL_S` (1 h) |
-| Attachment in a marker folder | unreferenced, but may come back | `SCHEDULED_GRACE_S` (30 d) |
+| Space in both, plan A → plan B | the user picked another image | removed immediately |
+| Space in both, plan → none | detached; one click undoes it | **kept** |
+| Space gone | deliberate, but the image was imported and may be nowhere else | **kept** |
+| Space has a plan, plus another file of its own | an upload whose save was rejected | `PLAN_ORPHAN_TTL_S` (1 h) |
+| Marker in both, attachment dropped from its list | a trash button, promising nothing | removed immediately |
+| Marker gone | same call as a deleted space's plan | **kept** |
+| Attachment in `up_*` | a dialog that was never saved; no device owns it | `PLAN_ORPHAN_TTL_S` (1 h) |
+| Marker there, file it never listed | a rejected upload | `SCHEDULED_GRACE_S` (30 d) |
 
 **Config writes are serialized** (HP-1454-03). `_writeConfig()` chains onto a
 single promise: one `config/set` in flight, each carrying the revision the