Write down the trash requirement the code already implements

The traceability gate failed on an orphan tag: seventeen sites across
dr-catalog, dr-sync, dr-thumbs and the UI claim FR-CAT-15, and
requirements.md defines FR-CAT-1 through FR-CAT-14. Not a typo and not a
renumbering — the trash was built, designed and documented in the modules
that implement it, and the requirement itself was never written. An orphan
is the gate working: a tag naming an undefined ID would otherwise count as
covered, which is how a matrix comes to report coverage of things nobody
specified.

FR-CAT-15 now says what trash.rs does, in the terms the module already
argues: a soft delete moves the file into `.darkroom-trash/` and the
catalog records that it happened, because a flag alone would not survive
invariant 5.2.4 — the catalog is rebuildable from sources, so a rescan
would find every deleted file still in the library and re-index it. That
is also why the scanner exclusion is part of the requirement rather than
an implementation detail; the folder and the exclusion are one mechanism
and neither works alone. Permanent delete removes the file before the row,
a delete of something already gone counts as success, and the count and
bytes are shown before emptying.

docs/traceability.md is regenerated: 150 requirements, 71 covered, no
orphans.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/requirements.md

@@ -159,6 +159,22 @@ Lightroom `.lrcat` and a darktable `library.db`. Edit graphs are explicitly **no
 develop parameters do not translate meaningfully between pipelines, and a partial translation is
 worse than none. This is the path in for users with existing libraries.
 
+**FR-CAT-15 — Trash and permanent delete.** Deleting an image shall be reversible by default. A
+soft delete **moves the file** into a `.darkroom-trash/` folder under the library root and records
+in the catalog when it was trashed and the path it came from; restore moves it back to that path.
+Permanent delete removes the file first and the catalog row second, and a delete of something
+already gone counts as success.
+
+A flag alone would not survive invariant 5.2.4: the catalog is rebuildable from sources, so a
+rescan would find every "deleted" file still in the library and re-index it. The folder is the
+durable fact and the row is the convenience — which also means the scanner shall exclude the trash
+folder, and that a user can recover by hand without DarkRoom. Derived data keyed on the file
+(thumbnails, cached previews) is dropped when the image is permanently deleted, not when it is
+trashed.
+
+The trash shall be listable newest-first, with the count and total bytes it holds shown before any
+destructive action, since that figure is what tells the user whether they meant it.
+
 ### 3.2 RAW decoding
 
 **FR-RAW-1 — Format support.** Decode mainstream RAW formats. Minimum launch set: Canon (CR2,