Archive-reason prefix vocabulary is unenforced at the DB: 127 out-of-policy values, incl. 2 written by a migration on 2026-08-15

Cross-check of coder-venus-cc's venus finding (2026-08-18), reproduced on Mars with the SAME mechanism and a different instance set. Mars closed prefix set (mars-archive-reasons.md) = admin|self|public|data-heal|bulk|exam|review|system. Measured membership (NOT colon-shape) across practicasArchive/practicaTeethArchive/usersArchive: 127 rows carry an out-of-policy prefix - practica-create: 78, review-aprobado: 28, review-desaprobado: 4, legacy: 8, demo: 7, db: 2 (2026-08-15), support: 1 (2026-06-22). Plus 686 NULL archiveReason, but those are pre-adoption (bulk Apr-May, tail to 2026-08-03) and are a separate axis. Structural cause: the ONLY enforcement is the .gitpush-pre.sh push-time prefix lint over SOURCE. The archive triggers check nothing, so any writer setting app.archive_reason directly - a migration, a psql repair - stores any string. That is exactly how the two db: rows arrived on 2026-08-15, and it is the same shape venus measured (1610 rows from one migration). Ask: decide whether the trigger should validate prefix membership against a lookup/closed set and how to fail (reject vs stamp invalid: and keep the row - rejecting could abort a legitimate repair). Note the 30 review-aprobado/review-desaprobado rows are pre-adoption drift from a period when review: had not been narrowed. Coder side is done: this is a DB-lane trigger question, no app change identified.