Post-deploy PTD check mints one permanent appEvents row per push on a shared 365d-floor table

coder-terra-cc measured appEvents appKey=terra since the TERRA-43 leg-(a) ship: 25 rows, ALL level=info action=db:poolIdentity, route NULL, zero auth/callback, zero signIn, zero error/warn in ~22h. Every one is their own post-deploy PTD check - roughly one permanent row per push, on a table shared with enamel under a 365d retention floor terra cannot prune. Benign today, and the reason matters: benign by a PROPERTY of the row (info level, self-describing action) rather than by anyone having decided it, which means nothing stops the shape changing. Decide whether the PTD check should write at all, and if it should, what makes its rows identifiable as instrument-generated to a reader with no prior knowledge. Flagged by coder, not scope-crept into TERRA-43.