Reportes: dashboard de reportes por rol, reportes a medida, filtros y rangos de fecha

EPIC. Modulo /reportes de MovilBA: un dashboard que ofrece a cada usuario el conjunto de reportes que su rol habilita, mas reportes a medida, con filtros y rango de fechas. ESTADO DE PARTIDA (medido 2026-08-31 contra DEV por coder02-mba-l-cc, SELECT): - La tarjeta 'Reportes' YA existe en el home (src/app/page.tsx:64, icono 📊, clave RBAC 'reportes', path /reportes) y /reportes YA esta en el allowlist del proxy (src/proxy.ts:17). - PERO el recurso 'reportes' NO existe en la tabla resources (21 recursos, ninguno es 'reportes'), asi que hasAccess('reportes') da false para TODOS y la tarjeta no se renderiza para nadie. No es un 404 en produccion: es navegacion muerta. - Tampoco existe src/app/reportes/ en disco. No hay ruta. - Igual pasa con 'configuracion': tarjeta declarada, recurso inexistente. Vale revisarlo de paso, no es parte del alcance. ROLES REALES (tabla groups, DEV): ADMIN(11 usuarios), VEHICULOS_VIEWER(12), TRAMITES_PARQUE(7), DEV_SR(3), VIEWER(2), 'API Docs'(2), EDITOR(0), EDITOR_INSTALACIONES(0), usuarios_desactivados(0). El dashboard se tiene que apoyar en estos grupos, no en una lista de roles inventada. Ojo: los grupos con 0 usuarios son reales pero no ejercitados. COMO FUNCIONA EL RBAC HOY (src/lib/rbac.ts): permisos derivados por consulta - users_groups -> groups -> groups_permissions -> permissions -> resources, devolviendo {recurso: {actions:[]}}. Un reporte nuevo no necesita codigo de permisos nuevo: necesita FILAS en resources/permissions/groups_permissions. Eso es DDL/DML de datos, va por el carril db con item propio y GO fresco. ALCANCE (los hijos se filan aparte, esto es el paraguas): 1. Recurso RBAC 'reportes' + permisos + asignacion a grupos. Decidir la granularidad: un solo recurso 'reportes' con acciones, o un recurso por reporte. Esto condiciona todo lo demas, va primero. 2. Ruta /reportes (App Router) + pagina indice que lista SOLO los reportes que el usuario puede ver. 3. Catalogo de reportes: que reportes existen. Falta definirlo con Elazar - no inventar la lista. 4. Filtros y rango de fechas. REGLA DURA DEL PROYECTO: las columnas de auditoria NO son fechas de negocio (reference_audit_columns_are_not_business_dates); un rango de fechas tiene que decir CUAL fecha filtra y ser una fecha de negocio del libro RUTAP. 5. Reportes a medida (el usuario arma el suyo): definir si se guardan por usuario, si se comparten, y con que permiso. 6. Export. Regla vigente: hacia afuera el id de un colectivo es el 'dominio', nunca el 'id' interno (feedback_stakeholder_docs_carry_no_record_counts). RESTRICCIONES QUE APLICAN: - Todo valor enumerado sale del catalogo 'opciones' via v_opciones/v_ui_*, nunca texto crudo (.claude/rules/catalogos.md). - Ningun copy user-facing puede insinuar que el dato sea incompleto o poco fiable (feedback_no_self_disclaimers_in_user_facing_copy, BLOCKING). - Capas: repositories (solo Drizzle) -> services (logica) -> app/api/*/route.ts (HTTP). - Drizzle enumera columnas: cualquier vista nueva tiene que existir con las MISMAS columnas en DEV y PROD o la pagina da 500 con el typecheck en verde (reference_una_vista_de_prod_con_menos_columnas_que_el_modelo_drizzle_es_un_500). - El estado de un vehiculo se lee de la FICHA (vehiculos_datos_colectivos.estado_id), no del historial. PREGUNTAS ABIERTAS PARA ELAZAR (bloquean el diseño, no el filado): que reportes concretos se necesitan y para quien; si 'a medida' es elegir columnas/filtros sobre datasets fijos o un constructor libre; si hay que exportar a Excel/PDF o alcanza con la pantalla; y si esto entra antes del go-live tentativo 2026-09-07 o despues.