refac: article reads, story delete, no leaks, stored SEO status, rate limit, cleanup (%site%, article repo split, old lang repos, one default per site rule to domain)

features/article_list_localization.feature

@@ -122,7 +122,8 @@ Feature: Editorial article list by story and language
       Given the "Journal" dataset and an owner session
       When the client sends GET /v1/article/?group=story
       Then the coverage of story <story> is <coverage>
-      And each entry has id, lang, title, is_online, language_enabled and capabilities, like an entry of "translations" in features/article_story_lifecycle.feature
+      And each entry has id, lang, title, is_online, language_enabled, excluded_from_public, source_article_id and capabilities, like an entry of "translations" in features/article_story_lifecycle.feature
+      And each row has excluded_from_public, the flag of its representative version
       And missing_langs of story <story> is <missing>
 
       Examples:
@@ -160,6 +161,13 @@ Feature: Editorial article list by story and language
       Then its row has lang "", coverage with its single version, and missing_langs []
       And it never appears in the "not in" view of any language
 
+    Scenario: A mixed story is listed under Missing
+      Given story 31 holds article 31 (lang "") and article 32 (en), and story 33 holds article 33 (lang "") and article 34 (fr)
+      When the owner sends GET /v1/article/?group=story&tab=missing
+      Then stories 31 and 33 are listed, with the enabled languages they lack in missing_langs
+      And the version without language fills no language
+      And a story whose readable versions all lack a language is never listed
+
   Rule: Language selected means one row per version of that language
 
     Scenario: French selected
@@ -268,6 +276,12 @@ Feature: Editorial article list by story and language
       When the owner sends GET /v1/article/?group=story&seo=suggestions
       Then story 5 is listed once, with its own representative 501
 
+    Scenario: The SEO status is stored, not recomputed from every body
+      Given 40,001 versions whose SEO status was computed once
+      When the owner requests any page of ?group=story&seo=suggestions, with or without q
+      Then the status filter and counts.suggestions are evaluated in SQL on the stored status
+      And no body of a visible version is read except the representatives of the page
+
     Scenario: All filters combine with paging and stay stable
       Given 12 stories match
       When the owner requests pages 1, 2 and 3 of ?group=story&size=5 with the same filters