v1.46.5: audit of every automatic deletion

Owner's decision after the incident: a detached plan is never deleted, at any
age. v1.46.4 gave it a month; this makes it permanent and, more importantly,
writes the reasoning where the next change will trip over it — docs/SCOPE.md now
carries the standing rule. The component may delete a file only when a user
action says so. 'Nothing points at this any more' is not such an action, because
the two errors are not symmetrical: wasted disk is visible, cheap and
reversible; a deleted file is none of those.

Went through every other automatic deletion with the same question. One more
was wrong: houseplan/files/cleanup rmtree'd whatever folder the card named. A
partial migration leaves urls pointing into it — files/migrate deliberately does
not rewrite the ones it could not confirm — so those were live links to files
being deleted; and a wrong or stale id from any client destroyed a live device's
manuals. The server now reads the stored config under its lock and removes only
what nothing references, keeping the rest and saying so.

Also: a plan of a DELETED space now waits thirty days rather than an hour.
Deleting a space is deliberate; an hour is a short window to notice a misclick.

The rest came out clean: layout/delete and marker/room/space removal are all
confirm-guarded user actions, upload temporaries are never user-visible, and
dropping legacy 'segments' is a documented migration.

docs/SCOPE.md

@@ -66,6 +66,18 @@ refuse locks or be added to this paragraph.
 - Plan-level "security glance": one badge for "all locked / N open" (J2).
 - Threshold colouring for room-card metrics (J5).
 
+## Standing rule: never delete a user's file on an inference
+
+Fixed with the owner on 2026-07-28, after automatic collection removed two
+detached floor plans. The component may delete a file only when the user's
+action says so — replacing a plan, removing an attachment, deleting a device.
+"Nothing points at this any more" is not such an action: detaching a plan is one
+click and reversible, and the editor tells the user the file stays.
+
+The asymmetry is the whole argument. Wasted disk is visible, cheap and
+reversible; a deleted file is none of those. Where the evidence is weak, keep
+the file — and if a future version wants to reclaim that space, it asks.
+
 ## Out of scope — never build, point users to the right tool
 
 - Automations, scenes, scripts, notifications → HA core.