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

02_device_lab/ansible/README.md

@@ -9,6 +9,8 @@ del blade. Es la única forma sensata de hacer esto con el hardware que hay.
 
 ## La arquitectura
 
+![Arquitectura de la granja](../../assets/arquitectura.svg)
+
 ```
 Dell PowerEdge M1000e — 16 blades
 │
@@ -45,6 +47,13 @@ sudo apt install ansible
 - Salida a internet, o un mirror local de `download.docker.com` y `deb.debian.org`
 - Kernel con `binder_linux.ko` (el estándar de Debian lo trae)
 
+**Chasis** — un módulo de I/O en **A1** como mínimo. La Fabric A es la Ethernet integrada (LOM) de
+cada blade, así que **no hacen falta tarjetas intermedias**; las Fabrics B y C sí las exigirían y
+no se usan aquí. Si en A1/A2 hay un módulo **switch**, la conmutación entre blades es interna al
+chasis, que es lo que necesita `macvlan`. Si hay un módulo de **paso a través**, salen 16 RJ-45 al
+exterior y la conmutación depende de un switch externo. Ver
+[hardware_m1000e.md](../hardware_m1000e.md).
+
 **Ejecuta siempre desde este directorio** (`ansible/`) — `ansible.cfg` y las rutas de roles son
 relativas a él.
 
@@ -121,6 +130,8 @@ Se controla con `redroid_network_mode` en `group_vars/all.yml`.
 Cada Android detrás de NAT de Docker; adb en `<ip_blade>:<puerto>`, empezando en 5555.
 Funciona en cualquier sitio sin saber nada de la LAN. Es el modo con el que empezar.
 
+![Los dos modos de red](../../assets/red-modos.svg)
+
 ### `macvlan` — el que quieres para `oasis_mobile`
 
 Cada Android coge una **IP real de la LAN** a través del switch FlexIO del chasis. Los dos APKs