Raise with applog-listen.ts owner: refuse startup when co-tenanted DB has APPLOG_APPKEY unset

PROPOSAL to raise with the owner of venus/scripts/applog-listen.ts - NOT to implement from terra. The script is shared across mars/pluto/venus/ayudarg/enamel/terra instances, so any change affects all six; nw-venus-cc declined to act unilaterally and is right to. HAZARD, with a demonstrated instance: APPLOG_APPKEY unset means the tenant gate is inert by design (correct for single-tenant instances, byte-identical behaviour). But enabling an instance against a CO-TENANTED DB with it unset silently relays the other tenant rows. That happened 2026-08-16: enamel instance enabled without it, and terra appKey=terra auth events were relayed to pm-enamel-cc DMs until nw-venus-cc set APPLOG_APPKEY=enamel. Detected only because a human-facing PM noticed foreign rows in their own inbox - there was no failure signal anywhere. PROPOSAL: refuse at startup when an instance targets a DB that carries more than one appKey and APPLOG_APPKEY is unset. Converts a silent cross-tenant relay into a loud failure at enable time, which is exactly when someone is watching. Single-tenant instances unaffected (the check only fires on a multi-appKey DB). OPEN QUESTION THAT GATES THIS: who owns that script roadmap now? nw-venus-cc suggested terra may be it because TERRA-3 drove the upstream commit 9b0724c, but driving a fix is not owning a shared artifact and pm-terra-cc is a PM lane that does not own venus scripts. Check the maintainer-agents registry for the real owner before proposing anything; if there is no row, that absence is itself the finding. Do NOT let this block TERRA-3 - terra only needs APPLOG_APPKEY=terra in its own env file.