PLAN DE MEJORA — DISEÑO DEL MODELO 3D DEL B-17 (juego "aviones")
==================================================================

DIAGNÓSTICO
-----------
El modelo (public/src/models/b17.js) se armó a ojo, en espacio local,
pegando ~150 formas sueltas (cilindros, cajas, planos) con posiciones y
tamaños escritos a mano. El propio código lo delata: hay comentarios del
tipo "r≈1.39", "r≈1.32" — radios del fuselaje aproximados a mano para
calcar las ventanas encima. Cuando la aproximación falla, la ventana
queda enterrada dentro de la pared del fuselaje (por eso se ven
"tapadas"), y como cada pieza (ala, cola, cúpulas, decals) es una caja o
plano suelto que nadie verificó visualmente contra las demás, quedan
gaps o superposiciones raras.

Nunca hubo cámara exterior en el juego (solo vista interior / torretas)
para poder ver el avión de afuera y detectar esto — probablemente por
eso nadie lo notó hasta ahora.

Es arreglable, y el refactor reciente a arquitectura modular con ECS
(miniplex) lo deja más fácil: models/b17.js quedó como una función pura
y aislada, sin lógica de juego mezclada, así que se puede iterar sin
miedo a romper el resto.

PLAN
----
1. Instrumentar una vista exterior temporaria (cámara libre tipo
   "flyby" fuera del avión, solo para debug, no se shipea) — sin esto
   estaría corrigiendo números a ciegas otra vez.

2. Catalogar los defectos con capturas reales desde varios ángulos
   (perfil, 3/4 morro, 3/4 cola, planta) para tener una lista concreta
   de qué está mal, en vez de adivinar.

3. Arreglar la causa raíz de los "no coinciden": reemplazar los radios
   de fuselaje puestos a mano (xOut de las ventanas, el borde de las
   alas, etc.) por un cálculo real a partir del mismo perfil que ya
   define el fuselaje — una función radioFuselajeEn(z) que interpola el
   array de segmentos, así todo lo que se apoya sobre el casco
   (ventanas, raíz del ala, decals) usa el radio verdadero de esa
   sección en vez de una estimación.

4. Prolijar las ventanas tapadas: moverlas estrictamente por fuera de
   la superficie sólida (con el margen que ya calcula el paso 3) para
   que no queden enterradas.

5. Evaluar si vale la pena cambiar el fuselaje de "9 cilindros
   apilados" a un único LatheGeometry revolucionado sobre el mismo
   perfil — una sola malla continua en vez de piezas cosidas, lo cual
   mata de raíz el problema de "hecho por partes" (es más laborioso,
   así que queda como opción, no como obligación).

6. Re-captura y comparación contra las fotos del paso 2 para confirmar
   que se resolvió, antes y después.

NOTA
----
Las capturas headless en este sandbox (Chromium + software rendering)
se cayeron de forma intermitente durante la verificación del refactor
anterior — funcionan, pero no al 100% confiables, así que los pasos 2 y
6 pueden llevar algún reintento.