fix: don't burn a job attempt when the browser is unavailable

A job's attempt is incremented at lease time, then the dispatcher acquires
the headless browser. When the browser was down or mid-restart, acquire()
failed and the error was ack_failed — so during an outage the whole pending
backlog was chewed to `dead` within minutes while workers hot-looped.

Add SyncOutcome::BrowserUnavailable: the dispatcher returns it instead of
propagating the acquire error, and the daemon releases the lease (refunding
the attempt, like the cancel/session paths) and backs off, so an outage is
treated as an infrastructure blip rather than per-job failures.

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

backend/src/crawler/content.rs

@@ -71,6 +71,13 @@ pub enum SyncOutcome {
     /// Session probe failed mid-sync (avatar selector missing on the
     /// chapter page). Caller should abort the whole crawler run.
     SessionExpired,
+    /// The headless browser could not be acquired (down or mid-restart).
+    /// Produced only by the queue dispatcher (which calls `acquire()`); it is
+    /// an *infrastructure* outage, not a job failure, so the daemon returns the
+    /// job to `pending` WITHOUT burning a retry attempt. `sync_chapter_content`
+    /// itself never returns this — callers that already hold a lease can treat
+    /// it as unreachable.
+    BrowserUnavailable,
 }
 
 /// Per-chapter max fetch attempts when TOR is configured. `N = 3` means