fix(files): check the quota BEFORE the destructive blob write

Self-review of this branch caught a data-loss bug I introduced with the
per-app / group files ceilings: the quota check ran AFTER the blob write.

`write_atomic_at` renames the new bytes over the FINAL path, so by the time
the ceiling refused an update the previous bytes were already gone. The
per-app path then unlinked the blob (row survives, file destroyed — every
read 404s); the group path left the new bytes in place under the old row's
checksum (every read fails `Corrupted`). Either way a user permanently lost
a file merely by exceeding a quota — a strictly worse outcome than the
unchecked-update bypass the ceiling was added to close.

The check now precedes the write on create AND update, per-app and group. As
a bonus this stops an over-quota caller driving unbounded write+unlink disk
churn: the ceiling now bounds I/O, not just stored bytes. The blob still goes
down inside the transaction, under the advisory lock, so a rollback unlinks
it and nothing can reference it in between.

The original test passed against the bug: it asserted the refused update did
not change the stored byte TOTAL — true, while the blob was already
destroyed. The regression test now reads the file back through the
checksum-verifying `FsFilesRepo::get`, and was confirmed to fail with
`Corrupted` against the old ordering.

Also in the KV writer (same file): drop the redundant pre-read on the hottest
write path. `set`/`set_if` did a SELECT purely to learn whether the write
would add a row, when the upsert already returns the previous value. Check
after the insert instead (`>` not `>=`) and let the transaction roll back on
refusal — identical outcome, one round-trip fewer, and an update pays nothing
at all. `kv_repo::get_on` and `FsFilesRepo::final_path` are now unused and
deleted; `FilesRepo::delete` delegates to the `delete_meta_on` + `unlink_blob`
helpers rather than re-implementing them.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

crates/manager-core/src/files_repo.rs

@@ -209,11 +209,6 @@ impl FsFilesRepo {
         }
         Ok(())
     }
-
-    fn final_path(&self, app_id: AppId, collection: &str, id: Uuid) -> PathBuf {
-        final_path_at(&self.config.root, &app_owner_dir(app_id), collection, id)
-    }
-
     fn write_atomic(
         &self,
         app_id: AppId,
@@ -468,42 +463,14 @@ impl FilesRepo for FsFilesRepo {
         id: Uuid,
     ) -> Result<Option<FileMeta>, FilesRepoError> {
         Self::guard_collection(collection)?;
-        // SELECT + DELETE in one tx; unlink afterwards (outside the tx).
-        let mut tx = self.pool.begin().await?;
-        let row: Option<FileRow> = sqlx::query_as(
-            "SELECT id, collection, name, content_type, size_bytes, \
-                    checksum_sha256, created_at, updated_at \
-             FROM files WHERE app_id = $1 AND collection = $2 AND id = $3 \
-             FOR UPDATE",
-        )
-        .bind(app_id.into_inner())
-        .bind(collection)
-        .bind(id)
-        .fetch_optional(&mut *tx)
-        .await?;
-
-        let Some(row) = row else {
-            tx.rollback().await?;
-            return Ok(None);
-        };
-
-        sqlx::query("DELETE FROM files WHERE app_id = $1 AND collection = $2 AND id = $3")
-            .bind(app_id.into_inner())
-            .bind(collection)
-            .bind(id)
-            .execute(&mut *tx)
-            .await?;
-        tx.commit().await?;
-
-        // Row is gone; unlink the bytes. A failure here leaves an orphan
-        // file (reclaimed by a future sweep) — not fatal.
-        let path = self.final_path(app_id, collection, id);
-        if let Err(e) = std::fs::remove_file(&path) {
-            if e.kind() != std::io::ErrorKind::NotFound {
-                tracing::warn!(path = %path.display(), error = %e, "files: unlink after delete failed (orphan)");
-            }
+        // `DELETE ... RETURNING` is one statement, so the old SELECT-FOR-UPDATE
+        // + DELETE pair is unnecessary. Unlink only AFTER the row is gone: the
+        // reverse order would destroy the bytes of a row that a failure keeps.
+        let meta = delete_meta_on(&self.pool, app_id, collection, id).await?;
+        if meta.is_some() {
+            unlink_blob(&self.config.root, &app_owner_dir(app_id), collection, id);
         }
-        Ok(Some(row.into_meta()))
+        Ok(meta)
     }
 
     async fn list(