bugfix: wrap manga + chapter uploads in a DB transaction

Previously a storage failure mid-chapter-upload left a partial chapter
row pointing at a `page_count` that didn't match what was on disk, plus
any successfully-inserted page rows. Same shape for a manga create
where the cover put or cover_image_path UPDATE failed after the manga
row was already inserted.

Fix at the DB layer: open `pool.begin()` at the start of the create,
do all DB writes against `&mut *tx`, commit only after the full
sequence succeeds. If anything before commit fails, the transaction is
rolled back on drop and the DB stays consistent. Bytes already written
to storage on a rolled-back transaction become orphans on disk; a
future reaper can sweep them, and we prioritise DB consistency over
storage tidiness in this branch.

- repo::manga::create / set_cover_image_path: signature changed to
  `impl PgExecutor<'_>` so handlers can pass either `&PgPool` or
  `&mut *tx`. set_cover_image_path is new — replaces the inline
  `UPDATE` in the manga upload handler so the call site stays
  consistent.
- repo::chapter::create / set_page_count: same shape.
- repo::page::create: same.
- api::mangas::create and api::chapters::create both open a
  transaction around their DB writes; storage puts happen inside the
  transaction window (since they must precede the page-row insert), so
  a failed put aborts before commit.

New integration test (api_uploads::chapter_upload_rolls_back_when_
storage_fails_mid_loop) uses a `FailingStorage` helper that errors on
the N-th `put`. With N=1 (page 2 fails), the handler returns 500 and
the chapter + page tables stay empty.

`harness_with_failing_storage` is exposed alongside the existing
`harness` so future tests can reuse it for other fault-injection
cases.

Lockstep version bump to 0.9.3.

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

backend/src/api/chapters.rs

@@ -112,8 +112,15 @@ async fn create(
         });
     }
 
+    // Transactional create. If any storage put or page-row insert
+    // fails mid-loop, the chapter row + any earlier page rows are
+    // rolled back so we don't leave a chapter with stale page_count=0
+    // and orphaned page rows. Bytes already written to storage on a
+    // rolled-back transaction become orphans on disk; a future reaper
+    // can sweep them. DB consistency wins over storage tidiness here.
+    let mut tx = state.db.begin().await?;
     let mut chapter = repo::chapter::create(
-        &state.db,
+        &mut *tx,
         manga_id,
         metadata.number,
         metadata.title.as_deref(),
@@ -128,17 +135,15 @@ async fn create(
             manga_id, chapter.id, nnnn, page.ext
         );
         state.storage.put(&key, &page.bytes).await?;
-        repo::page::create(&state.db, chapter.id, page_number, &key, page.mime).await?;
+        repo::page::create(&mut *tx, chapter.id, page_number, &key, page.mime).await?;
     }
 
     let page_count = pages.len() as i32;
-    sqlx::query("UPDATE chapters SET page_count = $1 WHERE id = $2")
-        .bind(page_count)
-        .bind(chapter.id)
-        .execute(&state.db)
-        .await?;
+    repo::chapter::set_page_count(&mut *tx, chapter.id, page_count).await?;
     chapter.page_count = page_count;
 
+    tx.commit().await?;
+
     Ok((StatusCode::CREATED, Json(chapter)))
 }