spb/api-ka

- SERVICES += houseka, rentka : houseka avait deja son collecteur/modele/env
  (commit eb543c9) mais restait hors de la boucle de supervision et des
  routes ; rentka est integre de bout en bout (RentkaData, rentka_collector
  offset/2000 comme lou-ka, RENTKA_SOURCE_URL dans .env -> M4M36:8125,
  cadence attendue 1 h).
- connector_health poll desormais les 11 apps (houseka 17 sources,
  rentka ~680 sources au premier run).
- Docstrings 9 -> 11 services.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- collecteur houseka (table houseka_data, HOUSEKA_SOURCE_URL M4M64b:8098)
- supervision connector_health : cadence 4 h
- KA Agent : catalogue de sites, DETAIL_URLS/FICHE_URLS (/property), recherche
  transversale (maisons Canada hors Quebec)
- CORS : house-ka.com

Le registre connector_health est persisté et jamais purgé : une source
désactivée côté app (ex. stores fabri-ka enabled=0) restait broken/stale à
perpétuité et les agents gardiens la missionnaient sans fin (2026-08-24 :
37 missions ka6 sur origin-north.ai). Désormais :
- nouvelle colonne last_seen (dernière apparition dans une fenêtre de sync,
  ALTER TABLE appliqué en prod + backfill sur checked_at) ;
- statut retired si la source est déclarée désactivée par l app
  (disabled_stores/disabled_sources du /api/stats — 58 sources fabri-ka
  retirées au premier run) ou absente de tout journal depuis > 14 j ;
- une source retired qui réapparaît dans le journal est réévaluée
  normalement (last_seen remis à jour, statut recalculé) ;
- retired exposé dans les résumés (monitoring, /health) et le détail
  (last_seen ajouté), jamais alerté, ignoré par les gardiens (trigger
  broken/stale inchangé).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Sans marge, les sources en bord de cycle oscillent entre ok et stale
(jobka/lassonde à 2,3 h pour un seuil de 2 h ; fabrika en bord de rotation
de ~11 h pour un seuil de 24 h).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Revue du parc 2026-08-23 : les « brisés » niddamour, courtemanche,
place_florimay, atlas_immo étaient des sources sans inventaire en ligne
(vérifiées à la main) qui synchronisaient ok à 0 résultat.

- un 0 résultat n est suspect que si la médiane historique de la source
  est ≥ 1 ; sinon c est un vide légitime (streak remis à zéro)
- une source dont la dernière synchro observée est saine n est plus
  marquée stale même si son dernier succès avec résultats est ancien
- tests mis à jour + 2 nouveaux cas (53 verts)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Les apps sœurs n exposent par défaut que ~20 entrées de sync_log (~11 min
d activité pour lou-ka et ses ~200 sources) alors que le poll est bi-horaire :
la quasi-totalité des sources n était jamais observée, d où 195 fausses
alertes stale le 2026-08-22 (82 sources lou-ka pourtant en pleine forme).
Le poller demande désormais une fenêtre de 6 h ; les apps qui ignorent le
paramètre gardent le comportement historique.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- Collecteur JobkaCollector (src/collectors/jobka_collector.py) : GET /api/jobs
  de job-ka (M3U96a:8096), pagination limit/offset (clé jobs, total annoncé),
  table jobka_data — pipeline standard fetch → checksum → dédup → backup pg_dump
  → collection_runs. One-shot validé : 7 953 offres actives collectées.
- Config : jobka ajouté aux SERVICES (9) + JOBKA_SOURCE_URL (.env/.env.example).
  Il hérite automatiquement du run quotidien 02:00, du backfill, du backup 03:30
  et des endpoints /api/v1/jobka{,/latest,/date/…,/stats}.
- Supervision : jobka dans connector_health (cadence attendue 1 h, recent_syncs
  par source + facteur de rotation — 200+ sources pour une fenêtre de 20) ;
  visible dans /api/v1/monitoring/connectors (19 sources + _app, tout ok).
- Stats : libellé Job·Ka ; page /stats à 9 services.
- Tests : 3 tests jobka (pipeline, pagination offset, registre) + compteurs
  8→9 — suite complète 51 passed.

Rien à changer côté CORS (job-ka.com déjà dans les origines) ni côté agent KA
(chercher_emplois pointe déjà sur www.job-ka.com/api/jobs).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- table connector_health (une ligne par service/source, upsert) + job
  src/monitoring/connector_health.py toutes les 2 h dans apika-scheduler
  (lecture seule des GET /api/stats des 8 apps sœurs, timeout 5 s,
  échec d'une app sans impact sur le job)
- classement : broken (≥3 échecs ou 0 résultat ×3), stale (>2× cadence,
  facteur de rotation au niveau source), degraded (<50 % de la médiane),
  ok — cadences par service (lou-ka 1 h … resto-ka 168 h)
- alertes logs/alerts.log uniquement sur transition vers broken/stale
  (anti-spam via l'état précédent mémorisé en table)
- endpoints publics GET /api/v1/monitoring/connectors(/{service}) +
  bloc connectors dans /health
- 15 tests (classement, parsing, anti-spam, endpoints) — suite 48/48

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>