feat(ti/activo-fijo): la depreciacion del parque mide solo equipo de computo

La escala de 5/3/2 años es la vida util de una computadora. Con impresoras, telefonos IP, monitores y switches dentro, la dona promediaba vidas utiles distintas y ademas arrastraba su cobertura al piso: el año de referencia se conoce en 578 de 954 activos (61%) del parque entero, y en 551 de 552 (99.8%) del de computo. El indicador pasa de declarar una cobertura mediocre a medir todo su universo; el % depreciado queda en 53.2 en vez de 55.4.

• _CATEGORIAS_COMPUTO = Escritorio, Laptop, PC Mini. Si el area da de alta una categoria de computo nueva --o el DAG renombra una de estas-- hay que agregarla ahi: la dona la ignorara en silencio y el unico aviso sera que su conteo baje. All in One queda FUERA por decision del usuario.
• El bloque depreciacion_computo va aparte y NO reemplaza a kpis: las tarjetas y los desgloses siguen hablando del inventario completo. Fundirlos haria que dos numeros de la misma pantalla dijeran "activos" para universos distintos.
• La leyenda nombra las categorias como ETIQUETAS bajo el titulo, no al pie: la acotacion cambia el numero, asi que tiene que leerse antes que el numero. Van neutras a proposito -- rojo, ambar y verde ya significan Depreciado/Alerta/ Vigente en esa misma tarjeta. Y salen de _meta.categorias_computo, la MISMA lista que se filtro: agregar una categoria cambia el numero y el texto juntos.

El detalle abre con esos filtros VISIBLES

extra dejaba de viajar oculto dentro de filtros y ahora siembra la seleccion de los filtros del modal: al entrar desde la dona, Categoria aparece con las tres palomeadas y el resto sin marcar. El usuario ve por que esta acotado el grupo y puede seguir filtrando desde ahi. Aplica igual a los otros dos drills que ya usaban extra (En stock -> Sin asignar; BYOD -> la empresa), que eran igual de invisibles. "Limpiar" vuelve a la acotacion de origen y no a vacio: si se abrio desde la dona de computo, no debe traer switches a una tabla que se pidio de computadoras.

Dos defectos del modal de detalle

• La consulta dependia de la IDENTIDAD del objeto de filtros, no de su valor. El padre reconstruye filtros en cada render, asi que el efecto se re-disparaba sin que nada hubiera cambiado y su cleanup marcaba cancel = true sobre la peticion en vuelo: la respuesta se descartaba y setData no llegaba a correr. Ese es el camino por el que la tabla se queda mostrando el primer resultado mientras los filtros parecen no hacer nada. Ahora la dependencia es el valor serializado.
• Limpiar un filtro del modal ENSANCHABA el grupo: set() escribe undefined al vaciar y el spread lo hacia pisar el valor de la pestaña, al reves del contrato que el propio codigo declara. conValor() quita las claves vacias y la pestaña vuelve a ser el piso.

Verificado contra el endpoint: la dona y su detalle cuadran exacto (Depreciado 293, Alerta 223, Vigente 35, Sin dato 1) y un filtro extra dentro del modal recorta a 96. npm run build en portal_ti OK, ci_validate_models.py OK, check_lookandfeel.py sin hallazgos.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com