Venus-resident monitoring has no external liveness watcher: every enamel alarm dies silently with its host

SPLIT OUT OF ENAMEL-43 so the residual is a row and not a sentence in a migration header. ENAMEL-43 names this gap honestly and does not close it; this row is where closing it lives. THE GAP. Every enamel monitoring instrument that exists or is planned - the outbox age alarm (ENAMEL-32), the emailOutbox drain, and the ENAMEL-43 pii-scan runner plus its alarm - is a venus user timer. Venus being down silences all of them at once, and nothing watches any of their liveness. Each alarm can report on its subject; none can report on itself. TWO CASES THAT BEHAVE DIFFERENTLY AND MUST NOT BE COLLAPSED. (1) VENUS DOWN: every unit stops together. No venus-resident instrument can close this, because the closing instrument is also on venus. (2) ONE UNIT DEAD, HOST UP: bad DSN, expired password, unit masked, unit failed, grant revoked. This case IS closable from venus by a heartbeat, and it is the case that actually happened here - the applog error rail ran dead for 16.8 days with the host healthy, which is a single dead consumer and not a host outage. READER BEFORE WRITER, AND THAT IS THE WHOLE POINT OF THIS ROW. The obvious move is to have each unit write a liveness heartbeat. Do NOT start there. A heartbeat nobody reads is not an instrument - that is precisely what the applog rail was, and the 16.8 days are the measurement of what a rail with no consumer is worth. Specify the READER first: what process, on what host that is not venus, reads the liveness rows and escalates on staleness, and who owns it. Once a real reader exists the writers are trivial and can be added per-unit. WHERE IT CAN TERMINATE. The only durable surface enamel holds that is not venus is the Supabase database itself. Liveness rows in opsProbeRuns are therefore the natural carrier, readable by anything with a DSN from any host. The reader is the part enamel does not own - it needs a fleet-level, off-venus owner, or an explicit ruling that enamel builds and hosts one on whey or lezama. NOT DECIDED HERE; that is the ask. COST NOTE MEASURED ON THE ENAMEL-43 DESIGN, so whoever picks this up does not rediscover it: service_role holds SELECT on opsProbeRuns and NOT INSERT. The existing heartbeat write rides fn_runAppEventsPiiScan being SECURITY DEFINER. So any NEW heartbeat writer needs either its own SECURITY DEFINER function or a direct INSERT grant, and the second widens a read-only alarm role past read-only. That is a real design constraint on the writer half, not a detail. BLOCKS NOTHING. ENAMEL-43 ships with the residual named in its header and a pointer to this row. This row is the termination, and it is open until a reader exists.