Etapa 3: publicar mapas en vivo sin reiniciar el server

[leocagli]

Parte de #2 (modo construcción). Depende de todas las issues de mutación.

Esta issue es la que hace que el modo construcción se sienta "en vivo" en vez de "editá y reiniciá".

Lo que ya existe

El server del juego hidrata game data desde la DB al arrancar y reporta la versión aplicada:

[GAME DATA] Objs hidratados desde DB: 1062. Version aplicada: 4875.
[GAME DATA] NPC templates hidratados desde DB: 340. Version aplicada: 4872.
[GAME DATA] Balance hidratado desde DB: 1. Version aplicada: 3811.

Ese mecanismo ya existe para objetos, NPCs, crafteo, fundición y balance. Falta el equivalente para mapas, y falta que ocurra sin reiniciar.

Alcance

1. Endpoint para publicar los cambios de un mapa (pasar de borrador a vivo).
2. El server de juego recarga ese mapa sin reiniciar el proceso.
3. Los jugadores que están parados en ese mapa reciben la versión nueva.
4. Separación entre borrador y publicado: se puede editar sin que los jugadores vean el trabajo a medias.

El problema difícil

Recargar un mapa con jugadores adentro no es trivial:

• Un jugador puede quedar parado donde ahora hay una pared
• Un NPC borrado puede estar en combate con alguien
• El cliente cachea los mapas y hay que invalidar ese caché

Hace falta decidir la política. Opciones razonables: reubicar a los jugadores afectados al tile caminable más cercano, o rechazar la publicación si hay jugadores en las zonas modificadas.

Criterios de aceptación

• Publicar un mapa aplica los cambios sin reiniciar el server
• Un jugador dentro del mapa ve los cambios sin reconectarse
• Un jugador que queda sobre un tile ahora bloqueado no queda atrapado
• Los borradores no son visibles para jugadores comunes
• El caché de mapas del cliente se invalida correctamente
• Tests de integración

Archivos relevantes

• server/src/loadObjs.ts, loadNpcs.ts, loadBalance.ts (patrón de hidratación a replicar)
• La invalidación de caché es del lado del cliente