Terra leg of EVO-83: CR + client-questions surface

Terra's leg of EVO-83 (fleet CR + client-questions surface, replacing Google Sheets/Docs). Filed after pm-terra-cc added terra to bwi; previously unfileable (no terra project row) and recorded only as an event on the parent. Shape inherited from EVO-83, not re-derived: TWO tables (changeRequests: client writes / we triage; clientQuestions: we write / client answers) - inverse authorship, different terminal condition. Do NOT fold into supportTickets. The reason is a TRIAGE COLLISION, not view pollution: terra shipped the first real supportTickets consumer in v0.9.0 (/sin-acceso access requests, category accesoCuenta), so folding CRs there puts client change-requests in the same staff queue as users locked out of the app - different urgency, different responder, wrong even with correct view filters. Status/priority from lookupOptions with params.terminal (new status = INSERT, not deploy); soft-delete + vActive*; updatedAt trigger from the first migration. BLOCKED on a shared-DB design decision owned by db-enamel-cc, not by terra. Terra rides ENAMEL's users table, so a client-facing principal added for terra is inherited by every enamel sub-app. Terra's input, from terra/pm/05-client-info.md (Elazar 2026-07-27): the client DOES authenticate - Puia is 'to be treated as a client as well - same client-role access (CR + Q&A sections)', and OPEN item 6 is account pre-creation for that client-role. Terra therefore has TWO client principals at different organisational levels (Prof. Dr. Jorge Pasart, Director; and Puia), which is already the case a single shared 'client' group value cannot express. No schema, no DDL, no route reserved. Nothing ships before db-enamel-cc rules the shared-users shape and audit-terra design-pings it (Class-A: touches the shared users/groups surface).