test(claims): corrections and contradictory dates keep each claim's own event time (#717, slice 5) - #927

Summary

Tranche 5 de #717, critère d'acceptation 3 (« Corrections and contradictory dates preserve provenance and uncertainty; do not invent a date »). Aucun test ne le prouvait de bout en bout. Le nouveau test tests_py/handlers/test_claim_event_time_supersession.py passe par le vrai pipeline (wiki_extract puis wiki_resolve, composition root des handlers, backend SQLite par défaut) sur quatre mémoires liées à la même entité : une décision datée au jour, la même décision avec une date contradictoire au mois, une correction datée qui la remplace (switched to … replaces), et une décision sans date.

Après résolution :

• chaque event_time vaut exactement ce que sa phrase énonce (la résolution écrit supersedes et des memos, jamais event_time) ;
• la claim remplacée garde sa date plus ancienne à côté du pointeur supersedes et du memo supersedes de la correction ;
• les deux dates contradictoires survivent avec leur précision, sous un memo conflict_candidate qui nomme la paire ;
• la claim sans date reste unknown : aucune date reprise des voisines ni d'extracted_at.

Cause racine de la tranche : pas de bug de code trouvé, le comportement était correct mais non prouvé. Aucun changement de code de production.

Refs #717

Type of change

• New feature (non-breaking change which adds functionality) — tests seulement

Test plan

• pytest tests_py/handlers/test_claim_event_time_supersession.py : 5 passed.
• Tests voisins (test_wiki_pipeline_sqlite, test_claim_event_time_persistence, test_claim_event_time, test_wiki_ir_event_time, test_wiki_extract_superseded) : 172 passed, 4 skipped (PostgreSQL absent).
• Mutation : faire réinitialiser event_time par update_claim_supersedes fait échouer 2 des 5 tests.
• ruff check, ruff format --check, scripts/check_craftsmanship.py : OK.

Note de conception : chaque extraction est horodatée à sa propre minute (UPDATE … extracted_at), car le résolveur ne remplace qu'une claim extraite strictement plus tôt et datetime('now') de SQLite a une résolution d'une seconde. Les dates d'événement ne sont jamais lues depuis ce champ.

Pas vérifié : la suite complète, pyright et les variantes PostgreSQL (torch ne se télécharge pas dans cet environnement ; le test est SQLite uniquement). La CI fera foi.

Audit notes

• Observation hors périmètre : le résolveur ordonne la supersession par extracted_at, pas par event_time. Une correction extraite avant le claim qu'elle corrige ne le remplacerait pas. Non modifié ici.

Reviewer checklist

• CHANGELOG.md updated under the appropriate section.
• No secrets / credentials / PII in the diff.

Tranches restantes de #717 : recherche (wiki_view sur event_time, décision de comparaison entre précisions), synthèse (_claims_for_memory, wiki_frontmatter), intervalles abrégés si décidé.

Generated by Claude Code