Merge remote-tracking branch 'origin/develop' into feat/radius_accounting

# Conflicts:
#	src/rust/lqos_config/src/etc/mod.rs
#	src/rust/lqos_config/src/lib.rs
#	src/rust/lqosd/Cargo.toml
#	src/rust/lqosd/src/main.rs

docs-es/v2.0/api-es.md

@@ -2,12 +2,19 @@
 
 ## Requisitos
 
-El servicio `lqos_api` (API del nodo) requiere una suscripción activa a LibreQoS Insight.
+A partir de LibreQoS 2.2, el servicio `lqos_api` usa la misma política de circuitos mapeados que LibreQoS:
 
-Esto es independiente de los límites base de shaping:
+- Las redes con 1.000 circuitos mapeados válidos o menos pueden usar la API sin una suscripción a Insight.
+- Las redes con más de 1.000 circuitos mapeados válidos requieren un derecho válido de API o Insight.
+- El conteo usa circuitos configurados únicos con mapeos válidos, no tráfico reciente. Varios dispositivos del mismo circuito cuentan una sola vez y las filas sin mapeo IP no cuentan.
+- Una licencia activa o un grant firmado almacenado localmente puede autorizar el acceso a la API por encima del límite gratuito.
+
+Es la misma población usada por el límite base de shaping:
 - `ShapedDevices.csv` puede contener entradas ilimitadas.
-- Sin una suscripción/licencia Insight válida, LibreQoS admite solo los primeros 1000 circuitos mapeados válidos al estado de shaping activo.
-- Conteos superiores de circuitos mapeados dependen de una licencia Insight activa.
+- Sin una licencia o grant con derecho válido, LibreQoS admite solo los primeros 1.000 circuitos mapeados válidos al estado de shaping activo.
+- Los conteos superiores requieren una licencia con derecho de API o Insight.
+
+El acceso solo a la API está disponible mediante el enlace **Try Insight** de la WebUI a la mitad del precio de Insight completo.
 
 ## Fuente de verdad y pruebas
 
@@ -16,6 +23,8 @@ Use Swagger en su nodo como referencia completa y superficie de prueba para la v
 - Puerto local directo de la API: `http://<node-ip>:9122/api-docs`
 - Si la WebUI usa HTTPS opcional con Caddy: `https://<hostname-o-ip-del-nodo>/api/v1/api-docs`
 
+En sistemas que usan HTTPS con Caddy gestionado, deje el listener de la API en loopback y acceda a la API mediante `/api/v1/`. `LQOS_API_LISTEN` es un override avanzado para despliegues que exponen intencionalmente el listener de la API en forma directa; no lo configure en sistemas con Caddy gestionado salvo que la exposición directa, el firewall, TLS y los controles de acceso de operadores se hayan planificado juntos.
+
 Use esta página como mapa de capacidades. Use Swagger para inventario completo de endpoints, esquemas request/response y pruebas en vivo.
 
 ¿Necesita definiciones de persistencia e impacto en runtime? Vea el [Glosario](glossary-es.md).
@@ -55,7 +64,11 @@ sudo systemctl status lqos_api
 La mayoría de endpoints requieren:
 
 - Header: `x-bearer`
-- Valor: su clave de licencia Insight
+- Valor: una clave local con nombre creada en **License & Services**, el token local heredado o su clave de licencia Insight/API-only
+
+Las claves locales autentican al cliente, pero no evitan el límite de licenciamiento por circuitos mapeados. Un administrador puede crear hasta 16 claves con nombre en **License & Services**. LibreQoS muestra cada clave una sola vez, guarda únicamente su resumen SHA-256 y metadatos no secretos en `/etc/lqos.conf`, y no puede recuperarla después. Copie de inmediato el valor completo `lqos_api_...` al cliente y trátelo como una contraseña.
+
+Las claves con nombre no caducan automáticamente. Revoque las que ya no necesite; la creación y la revocación pueden tardar hasta 30 segundos en surtir efecto en `lqos_api`. Las claves de licencia existentes y el antiguo `local_api.bearer_token` siguen siendo compatibles. La interfaz identifica este último como **Legacy local API key** y permite eliminarlo después de migrar los clientes.
 
 ## Qué pueden hacer los ISPs con la API
 

docs-es/v2.0/configuration-advanced-es.md

@@ -232,6 +232,7 @@ Notas:
 - Durante el shaping, los nodos virtuales se eliminan y sus hijos se promueven al ancestro no virtual más cercano (revisa `queuingStructure.json` para el plan físico activo).
 - `ShapedDevices.csv` aún puede usar un nodo virtual como `Parent Node` para mostrar/agrupar; LibreQoS adjuntará esos circuitos para shaping al ancestro no virtual más cercano (si el nodo virtual está en el nivel superior y no tiene ancestro no virtual, se tratará como sin nodo padre para el shaping).
 - Evita colisiones de nombres después de la promoción (dos nodos con el mismo nombre terminando al mismo nivel).
+- Queue Auto también puede virtualizar ramas de alta capacidad de agregación, uplink o AP representadas como nodos `Site` o `AP` cuando superan `queue_auto_virtualize_threshold_mbps` y tienen ramas de cola hijas. Esto evita que una rama lógica grande se convierta en un cuello de botella de una sola cola de CPU.
 
 #### Consideraciones de CPU
 

docs-es/v2.0/https-caddy-es.md

@@ -20,8 +20,15 @@ LibreQoS ofrece dos opciones simples:
 - Los operadores dejan de usar `http://tu_ip_del_shaper:9123` y pasan a usar `https://tu-hostname/` o `https://tu-ip-de-gestión/`.
 - LibreQoS mueve el listener de la WebUI a `127.0.0.1:9123`.
 - Caddy publica la WebUI y la documentación de la API por HTTPS.
+- En modo Caddy gestionado, las solicitudes de API se envían a `127.0.0.1:9122`, de modo que la API queda detrás del mismo origen HTTPS que la WebUI.
 - Swagger pasa a `/api/v1/api-docs` en el mismo origen HTTPS de la WebUI.
 
+## Overrides del listener de la API
+
+El modo Caddy gestionado espera que el servicio API permanezca en loopback y se alcance a través de Caddy en `/api/v1/`.
+
+`LQOS_API_LISTEN` es un override para despliegues avanzados. No lo configure en sistemas con Caddy gestionado, salvo que quiera exponer directamente el listener de la API y también haya planificado firewall, TLS y controles de acceso de operadores para ese listener directo.
+
 ## Si usa el modo de certificado local
 
 Cuando deja el hostname vacío, el certificado raíz local de Caddy se guarda en el host LibreQoS en:

docs-es/v2.0/insight-es.md

@@ -130,6 +130,8 @@ Sin un estado válido de licencia/grant de Insight o Local, LibreQoS admite solo
 
 Un estado válido de licencia/grant con derecho habilita conteos de circuitos mapeados por encima del límite predeterminado de 1000.
 
+A partir de LibreQoS 2.2, la API del nodo usa este mismo conteo de circuitos mapeados válidos únicos. El acceso a la API está disponible sin una suscripción a Insight para 1.000 circuitos mapeados o menos. Por encima de 1.000, la API requiere un derecho activo válido o un grant firmado almacenado localmente. Los clientes todavía deben autenticarse con una clave local con nombre, el token local heredado o una clave de licencia Insight/API-only. Los administradores crean y revocan las claves con nombre en **License & Services**; los cambios pueden tardar hasta 30 segundos en surtir efecto en `lqos_api`.
+
 El comportamiento predeterminado del límite de 1000 aplica cuando el estado de licencia/grant está:
 - ausente
 - expirado

docs-es/v2.0/integrations-splynx-es.md

@@ -27,7 +27,8 @@ Después, ejecute una sincronización manual y valide salidas antes de aumentar
 - Use la WebUI para confirmar que la importación y la profundidad del árbol son las esperadas.
 - Use WebUI para ajustes operativos diarios.
 - Cuando Splynx no puede inferir el padre de un circuito desde `access_device` o los metadatos del router, LibreQoS deja ese circuito sin padre para shaping en lugar de adjuntarlo a un sitio o AP sintético. Corrija el padre en Splynx o Topology Manager si debe aparecer bajo un sitio o AP real.
-- En modo `ap_site`, LibreQoS trata los Network Sites de Splynx como contenedores de sitio y las filas de monitoreo con `access_device = 1` como AP o nodos de acceso. Los contenedores de sitio grandes pueden virtualizarse automáticamente cuando superan `queue_auto_virtualize_threshold_mbps`, tienen ramas de cola hijas y no tienen circuitos conectados directamente al ID del sitio. Defina una anulación virtual del nodo en `false` cuando un sitio específico deba permanecer como cola física.
+- Si dos filas de hardware de monitoreo de Splynx tienen el mismo título, LibreQoS agrega el ID de hardware de Splynx a esos nombres duplicados de nodos de topología. Por ejemplo, dos AP llamados `Tower South` aparecen como `Tower South (1122)` y `Tower South (1980)`.
+- En modo `ap_site`, LibreQoS trata los Network Sites de Splynx como contenedores de sitio y las filas de monitoreo con `access_device = 1` como AP o nodos de acceso. Las ramas grandes de sitios y APs, incluidas ramas de uplink o agregación representadas como nodos `Site` o `AP`, pueden virtualizarse automáticamente cuando superan `queue_auto_virtualize_threshold_mbps`, tienen ramas de cola hijas y no tienen circuitos conectados directamente al ID del nodo. Defina una anulación virtual del nodo en `false` cuando un nodo específico deba permanecer como cola física.
 
 ## Validación en 5 minutos después de cambios Splynx
 

docs-es/v2.0/integrations-uisp-es.md

@@ -33,6 +33,7 @@ El ajuste `Root UISP Site` solo es obligatorio en modo de topología `full`. En
 - `network.json` queda para despliegues DIY o manuales.
 - Use la WebUI para confirmar que la importación y la profundidad del árbol son las esperadas.
 - En modo integración, trate ediciones de archivos como temporales.
+- En modo `full`, los switches, routers y radios de UISP exportados como ramas AP/dispositivo pueden usar virtualización Queue Auto. Consulte [Nodos virtuales](configuration-advanced-es.md#nodos-virtuales-solo-lógicos).
 
 ## Validación en 5 minutos después de cambios UISP
 

docs-es/v2.0/node-manager-ui-es.md

@@ -34,7 +34,8 @@ Esta página documenta las vistas clave de la WebUI (Node Manager) y su comporta
 - Las ediciones de tasa desde la página del árbol escriben overrides operativos `AdjustSiteSpeed` en `lqos_overrides.json`.
 - En compilaciones UISP `full`, un `integrationUISPbandwidths.csv` heredado se auto-migra a esos overrides en la siguiente ejecución de la integración cuando todavía no existen overrides operativos de tasa; en caso contrario, el CSV se ignora.
 - Las ediciones de tasa desde la página del árbol requieren sesión de administrador, un `node_id` estable y un nodo no generado. Los nodos generados/sintéticos de la integración permanecen en solo lectura en este editor.
-- La página del árbol mantiene `Node Details` como una tarjeta compacta de resumen y coloca los editores de override como filas compactas directamente debajo de la tabla de detalles.
+- La página del árbol mantiene `Node Details` como una cuadrícula compacta de resumen y coloca los editores de override como filas compactas directamente debajo.
+- `Limited By` estima el origen de la velocidad efectiva. Los valores pueden incluir `Base rate`, `Est. Parent`, `Est. Override`, `Est. Attachment`, `Est. Queue` o `Est. Mixed`. Pase el cursor o enfoque el campo para ver los detalles de descarga y subida.
 - La página del árbol ahora muestra el estado de `Topology Override` solo en modo lectura. Los cambios de padre y adjunto se movieron a `Topology`, y el panel de detalles del árbol enlaza directamente a Topology Manager para el nodo seleccionado.
 - Los saltos de adjuntos seleccionados en runtime se colapsan fuera de la jerarquía principal del árbol. Cuando un sitio usa actualmente un backhaul o radio path específico, `Node Details` lo muestra como metadato `Active Attachment` en el sitio en lugar de exponer ese adjunto como un nodo propio del árbol.
 - Los adjuntos alternativos inactivos de backhaul PtP/cableado también se eliminan del árbol runtime. `tree.html` muestra solo la ruta efectiva; los alternativos inactivos quedan visibles en Topology Manager y no como nodos runtime independientes.

docs-es/v2.0/quickstart-es.md

@@ -49,7 +49,15 @@ sudo /opt/libreqos/src/systemd_hotfix.sh install
 sudo reboot
 ```
 
-El instalador del hotfix configura el repositorio APT de LibreQoS en `https://repo.libreqos.com`, instala el conjunto parchado de paquetes `systemd` de Noble y fija esos paquetes para futuras actualizaciones.
+El instalador del hotfix configura el repositorio APT firmado de LibreQoS en `https://repo.libreqos.com`, instala el conjunto parchado de paquetes `systemd` de Noble y fija esos paquetes para futuras actualizaciones.
+De forma predeterminada, selecciona la versión actual del hotfix desde ese repositorio.
+Si Soporte de LibreQoS te indica que tu paquete instalado es anterior a v2.2, usa este comando de recuperación en su lugar:
+
+```bash
+sudo HOTFIX_PACKAGE_VERSION=255.4-1ubuntu9999+libreqos1 /opt/libreqos/src/systemd_hotfix.sh install
+sudo dpkg --configure -a
+sudo reboot
+```
 
 Después del reinicio, reanude la instalación:
 

docs-es/v2.0/stormguard-es.md

@@ -41,6 +41,8 @@ minimum_upload_percentage = 0.5
 
 Si está probando, comience con `dry_run = true`.
 
+Al deshabilitar StormGuard, o al volver a `dry_run = true` después de usarlo en modo activo, las colas administradas recuperan sus tasas garantizadas y límites máximos configurados, y se eliminan los ajustes adaptativos persistidos por StormGuard. Los ajustes administrados por el operador no se modifican.
+
 ## UI y depuración
 
 - WebUI (Node Manager) incluye una pestaña dedicada de StormGuard además de las vistas de estado y depuración.

docs-es/v2.0/treeguard-es.md

@@ -124,6 +124,8 @@ anterior.
 
 Las decisiones SQM por circuito de TreeGuard también son overrides de tiempo de ejecución. El scheduler no materializa los cambios SQM propiedad de TreeGuard de vuelta en el `ShapedDevices.csv` base, por lo que limpiar TreeGuard no reescribe permanentemente la política SQM definida por el operador.
 
+TreeGuard solo gestiona circuitos estáticos de `ShapedDevices.csv`. Los circuitos dinámicos, incluidos los overlays de promoción de IPs desconocidas, permanecen bajo el ciclo de vida de circuitos dinámicos y overlays de Bakery, y no se enrolan en la conmutación SQM de TreeGuard.
+
 TreeGuard también se niega a gestionar nodos que ya estén marcados con `"virtual": true` en el `network.json` base. Si existen overrides legados de TreeGuard para esos nodos, TreeGuard limpia ese estado legado y vuelve a respetar la definición base de la topología.
 
 Para la gestión SQM por circuito, TreeGuard trata los valores duplicados de `device_id` como colisiones de identidad inseguras. Si el mismo `device_id` aparece en más de un circuito dentro de `ShapedDevices.csv`, TreeGuard omite esos circuitos afectados y limpia cualquier override SQM de TreeGuard asociado a esos `device_id` duplicados.

docs-es/v2.0/troubleshooting-es.md

@@ -271,6 +271,8 @@ Checks recomendados:
 2. Revisar logs de `lqosd` para requested/allowed/dropped.
 3. Reducir circuitos mapeados (corto plazo) o ajustar licencia/límites (largo plazo).
 
+La API del nodo usa el mismo conteo a partir de LibreQoS 2.2. Con 1.000 circuitos mapeados o menos, confirme que haya una clave local con nombre (o una clave heredada/de licencia compatible) y que `lqos_api` esté en ejecución. Una clave nueva o revocada puede tardar hasta 30 segundos en surtir efecto. Por encima de 1.000, confirme además que el derecho efectivo de API o Insight sea válido.
+
 ### Códigos de problemas urgentes y primeras acciones
 
 WebUI muestra códigos legibles por máquina para triage rápido.

docs-es/v2.0/update-es.md

@@ -8,6 +8,8 @@ Si usas el puente XDP, el tráfico dejará de pasar por el puente mientras lqosd
 
 ```{important}
 Desde v2.0, la ingesta de circuitos mapeados depende de un estado válido de licencia/grant con derecho. Sin un estado válido de licencia/grant de Insight o Local, LibreQoS solo lee los primeros 1000 circuitos mapeados válidos al estado de shaping activo. Esto incluye estado local de grant/licencia expirado o inválido por cualquier motivo. Vea [Comportamiento de licenciamiento de Insight](insight-es.md#límites-de-circuitos-mapeados-y-estado-de-licencia) y [Solución de problemas](troubleshooting-es.md).
+
+A partir de v2.2, la API del nodo usa la misma política. Las redes con 1.000 circuitos mapeados válidos o menos pueden usar la API sin una suscripción a Insight; las redes mayores requieren un derecho válido de API o Insight. Las llamadas continúan autenticadas. Un administrador puede crear hasta 16 claves locales con nombre en **License & Services**; cada clave se muestra una sola vez, se guarda únicamente como resumen SHA-256 y se puede revocar. Las claves de licencia y el token local heredado siguen siendo compatibles, y los cambios pueden tardar hasta 30 segundos en surtir efecto.
 ```
 
 Ejecuta:
@@ -39,7 +41,15 @@ sudo /opt/libreqos/src/systemd_hotfix.sh install
 sudo reboot
 ```
 
-El instalador del hotfix configura el repositorio APT de LibreQoS en `https://repo.libreqos.com`, instala el conjunto parchado de paquetes `systemd` de Noble y fija esos paquetes para futuras actualizaciones.
+El instalador del hotfix configura el repositorio APT firmado de LibreQoS en `https://repo.libreqos.com`, instala el conjunto parchado de paquetes `systemd` de Noble y fija esos paquetes para futuras actualizaciones.
+De forma predeterminada, selecciona la versión actual del hotfix desde ese repositorio.
+Si Soporte de LibreQoS te indica que tu paquete instalado es anterior a v2.2, usa este comando de recuperación en su lugar:
+
+```bash
+sudo HOTFIX_PACKAGE_VERSION=255.4-1ubuntu9999+libreqos1 /opt/libreqos/src/systemd_hotfix.sh install
+sudo dpkg --configure -a
+sudo reboot
+```
 
 Después del reinicio, reanuda la actualización y reinicia los servicios:
 
@@ -100,6 +110,8 @@ sudo ./systemd_hotfix.sh install
 sudo reboot
 ```
 
+El instalador selecciona la versión actual del hotfix desde el repositorio APT firmado de LibreQoS. Soporte de LibreQoS puede proporcionar un valor `HOTFIX_PACKAGE_VERSION` para un incidente específico.
+
 Ejecuta los siguientes comandos para recargar los servicios de LibreQoS:
 
 ```shell