applog-listen category filters assume VENUS literals — both are INERT on pluto (security=0 rows, access=0 rows); four rails, one file, four vocabularies

FOUR RAILS, ONE FILE, PER-APP CATEGORY VOCABULARIES. Found by coder-pluto-cc, ratified pmmaster ms7i182h2vvs. NOT VENUS-324 and NOT VENUS-325 — its own item, four rails. MEASURED ON PLUTO'S DB: category='security' -> 0 rows; category='access' -> 0 rows. PLUTO'S ACTUAL VOCABULARY CONTAINS NEITHER. So BOTH category-keyed filters in the shared applog-listen rail are INERT ON PLUTO — the `security` bot-filter and LOG_ONLY_CATEGORIES={"access"}. VENUS OVER-SUPPRESSES (real SQL errors hidden under `security` — see VENUS-325), PLUTO UNDER-SUPPRESSES (bot rows would page). SAME SEAM, OPPOSITE SIGNS, AND NEITHER APP CAN OBSERVE THE OTHER'S HALF. The unit pins WorkingDirectory to venus/, so venus/mars/pluto/ayudarg all execute this one file against four different category vocabularies. THE STARTUP GUARD CANNOT CATCH IT: it errors when the COLUMN is absent, NEVER when the VALUE is unknown to the app — a check bounding a narrower question than the one asked, again. SCOPE: measure the actual category vocabulary of EACH of the four (five, incl. enamel) app DBs, then make the rail's category-keyed filters per-app and configuration-driven rather than shared literals. NOTHING ABOUT CATEGORY FILTERING IS TRUSTED ON ANY RAIL UNTIL THIS IS SCOPED. Co-owned with pm-pluto-cc per pmmaster's routing. Cross-references VENUS-325 (venus's over-suppression instance) and VENUS-324 (the same seam being refactored).