applog-listen@terra and @enamel LISTEN on a channel their database never signals - the shared enamel/terra DB has no notify trigger on appEvents, so those two apps have no real-time rail and are covered only by the digest default that was never rolled back

MEASURED 2026-10-06 while verifying VENUS-464. applog-listen@terra and applog-listen@enamel are both active running and hold a persistent LISTEN on channel applog_err against the shared enamel/terra Supabase (eprpywqwzsvrjeaforei). That database has NO notify trigger on public."appEvents". The only non-internal trigger is tg_appEvents_immutable calling fn_forbidAppEventsMutation. For contrast, pluto has trg_applog_err AFTER INSERT calling fn_notify_applog_err, whose filter is NEW.level IN (error, fatal, warn). So for terra and enamel there is no real-time path at all. The listener docstring says the LISTEN leg owns error/fatal rows "in near-real-time"; on these two apps that leg receives nothing, ever. The only thing that pages is the periodic catch-up sweep (APPLOG_CATCHUP_MS, default 5 min), which selects error/fatal newer than the watermark - so the effective latency is up to 5 minutes rather than near-real-time, and a fatal row is not treated differently from any other. Coverage is NOT currently lost, and that is why this has been invisible: terra.env and enamel.env carry no APPLOG_DIGEST_LEVELS line, so their digest runs at the default error,warn and still reports error rows. The missing trigger is masked by the rollout step that was never taken. Those two facts cancel out today and must not be fixed in the wrong order - setting APPLOG_DIGEST_LEVELS=warn on terra/enamel while no notify trigger exists would hand error/fatal ownership to a rail that cannot see them and open a real error-coverage hole on two apps. Order that is safe: install the notify trigger on the shared DB first, confirm a real-time page from each appKey, and only then set the digest levels. Note the DB is co-tenanted, so the trigger fires for both appKeys and each listener instance filters by APPLOG_APPKEY (fail-closed payload gate in parsePayload) - the trigger must therefore include appKey in the payload or the gate has nothing to read. Check that before writing the DDL. Also unverified by me and worth a census in the same pass: venus, mars and ayudarg. I hold read credentials for pluto and the enamel/terra DB only. Two of the three app DBs I could read disagree about this trigger, so the remaining three are unknown rather than assumed-correct - and the venus-side comment describing "the trigger" was wrong for both apps I measured. DDL belongs to the DB lane for that project, not to me; filing it where the stack is owned.