Collector 0.7.47: summary repairs never insert a null session, existing triggers migrate on upgrade, and the status heartbeat stays bounded

Collector 0.7.47 replaces 0.7.46, which was rolled back after its canary. The background session-summary repair no longer fails on a session with no id, ledgers already on 0.7.45 or 0.7.46 get the corrected repair triggers when they update, and the status check stays cheap even after a failed start.

• Summary repairs never insert a null session (#446). The repair triggers from 0.7.45 grouped an OR without parentheses, so some rows reached session_sync_summary_repairs without a session id and maintenance failed with a NOT NULL error. That was the 0.7.46 canary failure, also seen on one 0.7.45 host.
• Existing triggers migrate on upgrade (#447). An updated ledger replaces the old repair triggers instead of keeping them, so real 0.7.45 and 0.7.46 ledgers stop failing after the update. A crash mid-migration rolls back atomically, and all 23 summary triggers match a clean ledger.
• A maintenance failure stays visible (#447). The failure latch survives failed reads and heartbeats, and clears only after a successful maintenance pass.
• The status heartbeat is bounded (#447). With a status cache, a heartbeat does no SQL; Codex intake stays near 3 ms at a million pending rows.

Updating and rolling back:

• The trigger migration runs in one transaction at start. Rolling back to 0.7.45 restores that version's triggers through its own migration.
• One known limit (eco-6hoxj.163.145): if the collector fails to start before it builds its status cache, its heartbeat does a full status read until the cache exists.

Runtime CLI SHA256: 1d2f30af02426f8b9841884692e5c2230e9629bee64554132da8e0e84a15d3b9.

Qualification: typecheck, the full proof suite and system end-to-end qualification ran on the merged commit. The published package is the qualified artifact from that run.