weeklyReport es un kind sin fila: el reporte KPI semanal solo existe en vuelo y catchUp() no puede re-barrerlo — perdida silenciosa e indistinguible de una semana tranquila

Residual de PLUTO-520 / VENUS-353, levantado por coder-venus-cc y aceptado como pluto-side. practicas-kpi-report/route.ts:522 computa el reporte semanal, lo pre-renderiza y hace pg_notify(pm_triage, {kind:weeklyReport, text}). El payload no se persiste en ningun lado. El passthrough que ship-ea venus entrega best-effort: los kinds sin fila relay-ean y retornan antes de enqueue(), sin tocar el watermark — correcto, porque un id/timestamp sintetico es el estado cursor-ahead que VENUS-313 llama irrecuperable. Consecuencia: catchUp() barre FILAS de tabla. Un kind sin fila no puede ser re-barrido nunca. Si el daemon esta caido, reconectando, o el post del DM falla en el instante fijo del lunes 09:00 UTC, ese reporte se pierde permanentemente y en silencio. Por que importa mas que en los otros kinds del rail: un accessRequest o un supportTicket perdido es recuperable por catch-up y, si falla, la fila sigue en la app para que un humano la encuentre. El reporte semanal es la unica senal de PM que no existe en ningun otro lado, y dispara UNA vez por semana, asi que la ventana de falla no es chica respecto de la tasa de eventos: es el evento entero. Ademas falla hacia el lado que parece normal — no hay forma de distinguir "no llego el reporte" de "semana tranquila", que es exactamente como PLUTO-520 sobrevivio sin que nadie lo notara. Arreglo: el cron aterriza una fila (tabla tipo kpiReports: texto pre-renderizado + createdAt) y el daemon la barre como cualquier otra, en vez de que el payload exista solo en vuelo. weeklyReport deja de ser un kind sin fila y pasa al camino normal de table-sweep; el passthrough de venus queda para los kinds genuinamente sin fila que vengan despues. Lane db (DDL, migracion + contrato de sweep coordinado con venus). Class-A por DDL sobre esquema vivo.