fix(history): count distinct new chapter numbers, authoritative on detail

new_chapters_count over-counted when scanlations share a chapter number
((manga_id, number) is non-unique, migration 0013): COUNT(*) tallied rows,
so duplicate-numbered chapters inflated the badge. Switch both the list and
per-manga read-progress queries to COUNT(DISTINCT number), and drop the dead
COALESCE (an empty set counts as 0, and the NULL-number case is handled by
the predicate). Fix the misleading comment.

Expose new_chapters_count on GET /me/read-progress/:manga_id and drive the
detail page's "N new" badge from it, instead of recomputing over the
paginated chapter list — which under-counted series past 50 chapters and
disagreed with the homepage shelf. Read markers stay client-side over the
loaded chapters and are documented as by-number (all we persist).

Adds duplicate-scanlation tests at both endpoints.

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

backend/src/domain/read_progress.rs

@@ -46,6 +46,11 @@ pub struct ReadProgressForManga {
     pub chapter_number: Option<i32>,
     pub page: i32,
     pub updated_at: DateTime<Utc>,
+    /// Distinct chapter numbers past the last-read chapter — the detail
+    /// page's authoritative "new since last read" count (computed over all
+    /// chapters, not the client's paginated list). `0` when caught up or
+    /// the position is unknown. See [`ReadProgressSummary::new_chapters_count`].
+    pub new_chapters_count: i64,
 }
 
 #[derive(Debug, Clone, Deserialize)]