fix(files): review round 1, the server — the tray's window, the GC's locks, a file's origin, the upgrade path

- The queue keeps a done job by when it became done (ready_at), not by its last write: renaming,
  keeping or moving an old file, or the GC's expiry warning, no longer brings it back as just finished.
- GC expiry and eviction re-read each file under the asset→job locks the user routes take, and commit
  one file at a time: a delete, a re-download or a keep made while the GC runs is honoured, never a
  second release that frees a file another user still holds.
- A file records the origin it was placed under (download_jobs.source_key, migration 0105): an edit
  whose parent expired still goes back to its folder, not to Uploads.
- A folder a file is being put in is held (FOR SHARE) until it lands; a delete of it waits and takes
  that file home too, instead of failing on the foreign key.
- The hash route reads at most two files at once (429 past that) and holds no connection meanwhile.
- 0104's backfill dates old files by their request date only: no notice prod wrote names its job.
- The old DOWNLOAD_ROOT still finds the files; a files root that is not a mounted volume stops the
  worker and is logged by the API; the volume-copy recipe looks the project-prefixed names up.
- Stale comments about the /downloads mount and the Downloads page.

backend/alembic/versions/0104_job_ready_at.py

@@ -8,9 +8,8 @@ Create Date: 2026-10-12
 download that failed for days and then went through used to sit days down the list, under its
 request date. Every path to done stamps it, held by `ck_download_jobs_ready_at`.
 
-A done job from before has no record of that moment, except where its "ready to watch" notice is
-still in the owner's inbox (read notices are pruned past a cap): that notice was written the moment
-it finished. The rest take the request date, which is where they already sat.
+A done job from before has no record of that moment (its "ready to watch" notice never named the
+job, so it cannot be matched back), so it takes its request date, which is where it already sat.
 """
 
 import sqlalchemy as sa
@@ -26,12 +25,7 @@ def upgrade() -> None:
     op.add_column("download_jobs", sa.Column("ready_at", sa.DateTime(timezone=True)))
     op.execute(
         """
-        UPDATE download_jobs j SET ready_at = COALESCE(
-            (SELECT max(n.created_at) FROM notifications n
-              WHERE n.type = 'download_done' AND n.user_id = j.user_id
-                AND n.data->>'job_id' = j.id::text),
-            j.created_at)
-        WHERE j.status = 'done'
+        UPDATE download_jobs SET ready_at = created_at WHERE status = 'done'
         """
     )
     op.create_check_constraint(

backend/alembic/versions/0105_job_source_key.py

@@ -0,0 +1,37 @@
+"""A file remembers where it came from
+
+Revision ID: 0105_job_source_key
+Revises: 0104_job_ready_at
+Create Date: 2026-10-12
+
+`download_jobs.source_key` is the origin a file came from — the source folder it may go back to —
+recorded when it is placed. An edit used to work its origin out through its parent each time, and
+once the parent was deleted or expired it fell back to "upload": moved into an own folder, it could
+no longer go back to its folder, and deleting that folder sent it to Uploads to stay forever.
+
+A file in a source folder takes that folder's key. One already in an own folder is left NULL and
+keeps being worked out (`folders.source_key_for`), as before.
+"""
+
+import sqlalchemy as sa
+from alembic import op
+
+revision: str = "0105_job_source_key"
+down_revision: str | None = "0104_job_ready_at"
+branch_labels: str | None = None
+depends_on: str | None = None
+
+
+def upgrade() -> None:
+    op.add_column("download_jobs", sa.Column("source_key", sa.String(260)))
+    op.execute(
+        """
+        UPDATE download_jobs j SET source_key = f.source_key
+          FROM file_folders f
+         WHERE f.id = j.folder_id AND f.kind = 'source'
+        """
+    )
+
+
+def downgrade() -> None:
+    op.drop_column("download_jobs", "source_key")