Ajustar al manual del M1000e, añadir diagramas y docs de operación

Especificaciones tomadas del manual del propietario del gabinete
PowerEdge M1000e (Dell, modelo BMX01, rev. A06, oct. 2019), que corrige
el spec sheet comercial usado hasta ahora.

Hardware:

- Peso máximo 200,5 kg, no 179. Profundidad 75,5 cm
- Seis fuentes y nueve ventiladores obligatorios, se usen 3 blades o 16.
  Toda bahía vacía necesita relleno
- Conector CEI/IEC C20 a 16 A. La fuente de 3.000 W exige 200-240 V
- Irrupción de 55 A por fuente durante 10 ms: un magnetotérmico de curva
  C salta, hace falta curva D
- Temperatura de funcionamiento continuo 10-35 °C
- ECM obligatorio con blades M630 de 120 W o más, o por encima de 30 °C

Red:

- Fabric A (ranuras A1/A2) es la Ethernet integrada de cada blade, así
  que no hacen falta tarjetas intermedias. Fabrics B y C sí las
  exigirían y no se usan
- Pendiente saber si en A1/A2 hay un switch o un módulo de paso a
  través: cambia el montaje de red por completo

Costes recalculados: el suelo fijo del chasis sube de 350 a ~500 W al
contar los nueve ventiladores, los módulos de I/O y las pérdidas de las
seis fuentes. 360 €/mes a 24/7, 59 €/mes por ventanas. Que las fuentes y
los ventiladores sean obligatorios convierte en hecho documentado lo que
antes era estimación: los pilotos parciales en el chasis son el peor
caso posible.

Documentación:

- assets/ con cuatro diagramas SVG propios: arquitectura, chasis, stack
  de software y modos de red
- docs/usabilidad.md: órdenes, flujos de trabajo, problemas conocidos y
  ergonomía del hardware
- Diagramas ASCII del panel frontal, el posterior y la topología de
  fabrics en hardware_m1000e.md
- Eliminada la parte de charla y divulgación, fuera del alcance del repo

docs/seguridad.md

@@ -25,7 +25,7 @@ Incluye los fallos que introduce el propio código de este proyecto, no solo los
 
 ## S1 · adb sin autenticación sobre contenedor privilegiado — **crítico**
 
-El fallo más serio, y es una cadena de tres eslabones que por separado parecen asumibles:
+Una cadena de tres eslabones que por separado parecen asumibles:
 
 1. **adb no tiene autenticación** cuando escucha en TCP. Quien llega al puerto, entra.
 2. **Las imágenes de redroid son `userdebug`**, así que `adb root` funciona: shell de root dentro
@@ -33,19 +33,17 @@ El fallo más serio, y es una cadena de tres eslabones que por separado parecen
 3. **El contenedor es `privileged: true`** — redroid lo exige para acceder a binder. Un privilegiado
    ve los devices del anfitrión y puede montar su sistema de ficheros.
 
-Encadenado: **cualquiera que alcance el puerto 5555 de un blade acaba siendo root en ese blade.**
-No hace falta ningún exploit, solo `adb connect`.
+Encadenado: cualquiera que alcance el puerto 5555 de un blade acaba siendo root en ese blade, sin
+exploit, solo con `adb connect`. Con 45 dispositivos son 45 puertas.
 
-Y con 45 dispositivos son 45 puertas.
-
-**Qué se ha corregido hoy.** El compose ataba adb a `0.0.0.0` — todas las interfaces. Ahora hay
-`redroid_adb_bind_ip`, así que se puede atar solo a la interfaz interna del chasis:
+Corregido en parte: el compose ataba adb a `0.0.0.0`. Ahora hay `redroid_adb_bind_ip`, que permite
+atarlo solo a la interfaz interna del chasis:
 
 ```yaml
 blade-02: { ansible_host: 10.0.0.12, redroid_adb_bind_ip: 10.0.0.12 }
 ```
 
-**Qué falta, y es lo que de verdad cierra el agujero:**
+**Lo que cierra el agujero:**
 
 - **Red de laboratorio aislada.** VLAN propia para la granja, sin ruta hacia la LAN de casa ni
   hacia internet salvo lo imprescindible. Es la medida que importa; el resto son parches.
@@ -84,7 +82,7 @@ cada Android **con IP real en la red**, cada uno con S1 encima.
 
 - VLAN dedicada para la granja, con el coordinador como único puente.
 - Reservar el rango de IPs en el DHCP, o habrá colisiones con máquinas reales.
-- No usar la LAN de casa. Nunca.
+- No usar la LAN doméstica.
 
 ---