opciones.findByCategory lee la tabla cruda: el desplegable puede ofrecer una de las 34 opciones soft-deleteadas (marca_motor y categoria_regulatoria estan 100% muertas)

Hallazgo #6 del barrido MOVILBA-207 (audit-mba-l-cc, medido en PROD 2026-09-03). src/repositories/opciones.ts:97 (findByCategory, fuente de los desplegables) lee la tabla opciones CRUDA: ni filtro inline ni v_opciones. Lo consumen services/opciones.ts:106 y services/vehiculos.ts:547. opciones tiene 202 filas crudas y 168 vivas: 34 soft-deleteadas. Reparto por grupo: marca_motor 12 de 12 MUERTAS (catalogo entero), categoria_regulatoria 10 de 10 MUERTAS, estandar_emisiones 3 de 9, tipo_asociacion 3 de 3, aire_acondicionado 2 de 2, QA658_campo 2 de 2, unidad_propulsora 1 de 11, estado 1 de 7. RIESGO LATENTE, NO DEFECTO VIVO HOY: coder02 conto las filas de vehiculos_datos_colectivos que apuntan a una opcion muerta sobre las 8 columnas _id (estandar_emisiones, estado, adas_presente, mdvr, cabina_antivandalica, pantallas, wifi, regimen_servicio_modalidad) y da CERO. El cero tiene input: la tabla tiene filas. O sea el desplegable PUEDE ofrecer una opcion borrada pero hoy nadie la eligio. FIX: rutear findByCategory por v_opciones. OJO con QA658_campo, que parece basura de prueba en un catalogo de PROD y merece su propia pregunta. CORRECCION al reporte de audit: la cifra 'opciones.estado_id 2396/2396' no es medible - vehiculos.estado_id NO EXISTE como columna; el estado_id vive en vehiculos_datos_colectivos. Audit hizo bien en marcarla como a re-verificar antes de citarla.