fix: technical debts left by the Sites, Authors and SEO slices, plus backend support for the new Sites and Authors pagination

features/seo_sites_articles_integration.feature

@@ -8,8 +8,8 @@ Feature: SEO round, slice 4: Sites defaults, Articles search status, Integration
     Given the screens are SitesView (/settings/sites), ArticleView (/article, also reached as /articles), IntegrationView (/integration) and the Editor SEO panel (/article/:id/edit), inside DashboardShell, per docs/design/routes.md
     And the visual spec of record is docs/design/screens/sites.md ("Sites: SEO defaults", 5 states), articles.md ("Articles: search status", 3 states), integration.md ("Search and sharing"), editor.md (SuggestionList), docs/design/components.md (SeoStatusChip, SuggestionList), docs/design/seo-slices.md and docs/design/states.md ("SEO round"). Exact copy is read from those files and is not repeated here unless a scenario needs it
     And the board frames of docs/design/source/DirectoryFrame.dc.html (Sites form, SuggestionList), AppFrame.dc.html (Articles rows, cards and toolbar) and IntegrationPage.dc.html (group and index) are the layout tiebreaker
-    And this slice is SPA only and uses the API of features/seo_data_backend.feature and features/seo_output_backend.feature without change. No Go file changes
-    And the SPA calls, with relative URLs through useApi only: GET /v1/site/, POST /v1/site/ and PATCH /v1/site/{id} (site_name, title_template, default_description), GET /v1/article/ with the optional seo=suggestions parameter, and PATCH /v1/article/{id} with seo_dismissed. The Integration page makes no request
+    And this slice is SPA only and uses the API of features/seo_data_backend.feature and features/seo_output_backend.feature, plus counts.suggestions added by features/articles_pagination_api.feature. No other Go file changes
+    And the SPA calls, with relative URLs through useApi only: GET /v1/site/, POST /v1/site/ and PATCH /v1/site/{id} (site_name, title_template, default_description), GET /v1/article/ with the optional seo=suggestions parameter, whose response also carries counts.suggestions, and PATCH /v1/article/{id} with seo_dismissed. The Integration page makes no request
     And an article list item carries seo_status ("ready", "suggestions" or "hidden") and seo_suggestions (a count)
     And the SPA never re-implements a suggestion rule or an SEO status. It draws the status and the count the list returned
     And the API refuses a title_template without the exact, case-sensitive token %title% with 400 invalid_title_template, and refuses site_name above 100, title_template above 200 and default_description above 320 characters
@@ -306,23 +306,30 @@ Feature: SEO round, slice 4: Sites defaults, Articles search status, Integration
       And the switch, the chips and ?seo=suggestions behave exactly as with several sites
 
     Scenario Outline: The count on the switch
-      Given the count request answers <answer>
+      Given the switch is on or off
+      When the list response <answer>
       Then the switch reads <label>
 
       Examples:
-        | answer                        | label                                                 |
-        | total 3                       | "Needs attention" with the count "3" in the mono face |
-        | total 0                       | "Needs attention" with the count "0"                  |
-        | still pending                 | "Needs attention" with no count                       |
-        | status 500 or a network error | "Needs attention" with no count and no notice         |
+        | answer                                     | label                                                 |
+        | holds counts.suggestions 3                 | "Needs attention" with the count "3" in the mono face |
+        | holds counts.suggestions 0                 | "Needs attention" with the count "0"                  |
+        | has no counts.suggestions                  | "Needs attention" with no count                       |
+        | has not arrived yet (first load)           | "Needs attention" with no count                       |
+        | failed with status 500 or a network error  | "Needs attention" with no count and no extra notice   |
 
     @not-in-design
     Scenario: Where the count comes from
-      Given the switch is off
-      Then one extra GET /v1/article/?seo=suggestions&page=1&size=5 is sent with the current q, status and site, and its total is the count
-      And the count is read from the main response total when the switch is on, with no extra request
-      And the count request is refreshed whenever q, tab or site change, and never when only the page, the size or the sort change
-      And a failing count request never blocks the list, never shows a notice and never changes the URL
+      Given the switch is on or off
+      Then the count is counts.suggestions of the latest successful GET /v1/article/ response
+      And no request with seo=suggestions and size=5 is sent for the count
+      And the count does not change when only q, tab, site, sort, page or size change, because counts.suggestions is global like the tab counts
+
+    @not-in-design
+    Scenario: The count survives a page or search change that is still loading
+      Given the count "3" was shown from an earlier response
+      When a new list request is in flight
+      Then the switch keeps showing "3"
 
     Scenario: Needs attention: none
       Given ?seo=suggestions, no search, the tab "All", and the response is empty