Etapa 1: subida y almacenamiento de PNG para tiles

[leocagli]

Parte de #2 (modo construcción). Depende de la capa de persistencia.

Esta es la primera mitad del objetivo mínimo del proyecto: poder poner un PNG propio en el piso de un mapa.

Lo que hay que entender primero

El piso del juego no son imágenes sueltas colocadas en coordenadas. terrain.json define una paleta de tipos de tile, y cada tipo referencia IDs de gráfico del motor por capa:

"palette": {
  "1": { "graphics": [5500, 581],        "blocked": true },
  "3": { "graphics": [5500, null, 4894], "blocked": true }
}

Los gráficos viven como PNG numerados en el cliente (graphics/<n>.png) y están indexados en graficos.json, que define el recorte (frame) dentro de cada PNG.

Entonces "subir un PNG y ponerlo en el piso" son en realidad dos pasos, y esta issue cubre el primero: meter el PNG en el sistema de assets. El segundo (registrarlo como gráfico y pintarlo) va en las issues hermanas de esta etapa.

Alcance

1. Endpoint de subida de PNG con validación estricta:
   • Sólo PNG real (verificar magic bytes, no confiar en la extensión ni en el Content-Type)
   • Límite de tamaño en bytes y en dimensiones
   • Dimensiones coherentes con la grilla de tiles (el tile es de 32x32; definir si se acepta un múltiplo o sólo tiles sueltos)
2. Almacenamiento con un ID estable y deduplicación por checksum (subir dos veces el mismo PNG no debería generar dos assets).
3. Servir el asset por una URL que el cliente pueda consumir igual que los gráficos existentes.
4. Registrar el asset en la DB con quién lo subió y cuándo.

Criterios de aceptación

• Subir un PNG válido devuelve un ID de asset y una URL servible
• Un archivo que no es PNG se rechaza aunque tenga extensión .png
• Subir el mismo archivo dos veces devuelve el mismo asset (dedupe por checksum)
• Se rechazan archivos por encima del límite de tamaño o dimensiones
• El asset queda atribuido a la cuenta que lo subió
• Tests de integración incluyendo el caso del archivo falso

Consideraciones de seguridad

Subida de archivos por usuarios es superficie de ataque. Como mínimo:

• Nunca servir el archivo desde el mismo origen que ejecuta código, o servirlo con Content-Type forzado y X-Content-Type-Options: nosniff
• Re-encodear el PNG del lado del servidor en vez de guardar el original tal cual (evita PNGs con payloads embebidos)
• No usar el nombre de archivo del usuario para nada del path

Archivos relevantes

• api/src/server.ts (donde irían las rutas)
• El cliente sirve gráficos desde graphics/<n>.png y los indexa por graficos.json

[martinextrabox-netizen]

Revisé el estado actual de main y el PR #33 ya fusionado. La base existe, pero quedan dos criterios importantes de #5 sin cerrar: validatePngUpload sólo comprueba firma/IHDR y luego almacena los bytes originales (un PNG truncado o con payload adjunto puede pasar), y no hay tests de PNG/subida. Propongo completar el alcance con un cambio pequeño sobre lo ya fusionado: decodificar y re-encodear el PNG antes de calcular checksum/guardarlo, validar dimensiones reales y límites, deduplicar sobre la salida canónica, y añadir pruebas para archivo falso con firma PNG, PNG truncado/corrupto, payload adjunto, duplicado, límites y atribución. Mantendré los headers image/png + nosniff existentes y evitaré tocar las partes de edición de mapas de #6/#7. Puedo entregar PR y verificación reproducible en un día.

[grantfox-oss]

🦊 GrantFox — @martinextrabox-netizen has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #5)
2. Your PR will be reviewed by the Bitcoindefi maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox!

@martinextrabox-netizen's PR #76 was approved and merged by @leocagli.

🏆 @martinextrabox-netizen: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (48 total points). Track your full progress on GrantFox.

👏 Great work, @martinextrabox-netizen! Keep contributing to Bitcoindefi.