Sightings: a Reader report defers a Poll of a solitary Series (#103) (#108)

Closes #103.

A userscript PUT already carries the Latest Chapter the Reader's own browser read off the Series page. It may now stand in for a Poll, under one restriction and one ceiling:

- **Solitary Series only** — a Series two Readers share is Polled on schedule however recently it was sighted, so one Reader's mistake can never reach another's list.
- **One rest of standing**, and a **six-rest ceiling** (`sightingCeilingRests`, counted in the Site's own Rest): however many Sightings arrive, an unpolled Series is Polled.

Both live in the due query's HAVING clause (`Store.DueForLatestCheck`) — the same place the schedule has always been decided, so no timer and no second code path can disagree with it. No new query per scheduler round.

Judgement costs no extra request. `Poller.checkOne` already compares what the Site publishes against what is stored: a lower number contradicts the Sighting (Reader and both numbers logged), the same number confirms it, a higher number is the Site publishing and clears the attribution instead. Three contradictions stop that Reader deferring — their reports still write the Latest Chapter — and twenty consecutive confirmations forgive them, as does the owner's clear-marks control from #102.

One client change was required: both userscripts skipped the PUT when the number had not moved, so the case the whole mechanism exists for — visiting a Series with nothing new — never reached the backend. `reportLatestChapter` sends it, skipping only the local write and the re-render. A numberless PUT (favourite toggle, progress from a chapter page) is no Sighting and defers nothing.

Schema: migration `0011_series_sightings.sql` adds `series.latest_sighted_at` and `series.latest_raised_by`. Trust model, thresholds, and rejected alternatives with their citations: `docs/adr/0011-sighting-deferral-trust-model.md`.

Reviewed on both axes (spec against #103, standards against the repo's rules); the blocker — attribution surviving a Poll that overtook the report — is fixed and has a test that fails without the fix.

Verification: `go test ./...` green (needs Docker), `node --test userscript/test/*.test.js` 66 pass.
Reviewed-on: #108
Co-authored-by: Sulthan Zaki <sultankiki05@gmail.com>
Co-committed-by: Sulthan Zaki <sultankiki05@gmail.com>

backend/api_test.go

@@ -621,6 +621,46 @@ func TestPutDoesNotClobberLatestCheckedAt(t *testing.T) {
 	}
 }
 
+// Sighting deferral (issue #103) only reaches production through the PUT
+// handler: the store and poller can be right and the feature still dead if the
+// handler never records the report. Asserted where a client can see it - the
+// series stops being due the moment the PUT lands.
+func TestPutRecordsASighting(t *testing.T) {
+	s := newTestStore(t)
+	srv := newRouter(s, testConfig(), nil)
+
+	now := time.Now().UnixMilli()
+	hour := time.Hour.Milliseconds()
+	seedForCheck(t, s, "asura:x", "https://asurascans.com/comics/x", now-2*hour)
+	due, err := s.DueForLatestCheck("asura", now-hour, now-6*hour)
+	if err != nil {
+		t.Fatalf("DueForLatestCheck: %v", err)
+	}
+	if len(due) != 1 {
+		t.Fatalf("due before the PUT = %d series, want 1", len(due))
+	}
+
+	body := `{"key":"asura:x","site":"asura","series_id":"x",
+		"series_url":"https://asurascans.com/comics/x",
+		"last_chapter":"Chapter 5","last_chapter_num":5,
+		"latest_chapter":"Chapter 9","latest_chapter_num":9}`
+	req := httptest.NewRequest(http.MethodPut, "/bookmarks/asura:x", strings.NewReader(body))
+	req.Header.Set("Content-Type", "application/json")
+	rec := httptest.NewRecorder()
+	srv.ServeHTTP(rec, auth(req))
+	if rec.Code != http.StatusOK {
+		t.Fatalf("PUT status = %d, want 200 (body %s)", rec.Code, rec.Body.String())
+	}
+
+	due, err = s.DueForLatestCheck("asura", now-hour, now-6*hour)
+	if err != nil {
+		t.Fatalf("DueForLatestCheck: %v", err)
+	}
+	if len(due) != 0 {
+		t.Fatalf("due after the PUT = %d series, want 0: the handler recorded no Sighting", len(due))
+	}
+}
+
 // The userscript route is registered outside the web UI's Discord auth, so it
 // must keep working whatever the web config — see internal/userscript for the
 // handler's own behaviour. The credential in the path is the owner's derived