Etapa 5: espacio aislado de mapas de usuario con propiedad y cuotas

[leocagli]

Parte de #2 (modo construcción). Depende de la capa de persistencia. Primera pieza del objetivo final: que cualquier jugador pueda construir su mapa.

El problema

Si cualquiera puede crear mapas, hacen falta dos garantías:

1. Que un mapa de usuario no pueda romper el mundo oficial. Ni por error ni a propósito.
2. Que un usuario entusiasta no tire abajo el servidor. Sin cuotas, el primero que suba 500 mapas con mil NPCs cada uno arruina la fiesta para todos.

Lo que ya existe y hay que aprovechar

El motor ya tiene convención de rangos de ID de mapa, y el cliente rutea según el rango:

Rango	Uso actual
1 a ~500	Mundo oficial
500 a 599	Mapas locales estáticos
2.000 a 29.999	Retos
30.000 en adelante	Instancias dinámicas

Los mapas de usuario deberían tener su propio rango reservado. Así el aislamiento es estructural, no una regla que hay que recordar aplicar.

Alcance

1. Rango de IDs reservado para mapas de usuario, documentado, sin solapamiento con los existentes.
2. Propiedad: cada mapa tiene un dueño (la cuenta que lo creó) y sólo esa cuenta lo puede editar.
3. Cuotas por cuenta, configurables:
   • cantidad de mapas
   • peso total de assets subidos
   • cantidad de NPCs y objetos por mapa
4. Estados del mapa: borrador (sólo lo ve el dueño), propuesto (en cola de revisión), publicado (visible para todos), archivado.
5. Aislamiento de economía: definir explícitamente qué se puede colocar en un mapa de usuario. Poder poner pilas de oro o ítems valiosos sería una fábrica de dinero infinito.

Decisiones a resolver en la issue

• ¿Los mapas de usuario cuelgan del mundo oficial mediante portales, o viven en un espacio aparte al que se entra desde un menú? Lo segundo es mucho más simple y aísla mejor.
• ¿Se puede combatir y ganar experiencia en un mapa de usuario? Si sí, es explotable. Sugerencia para la primera versión: no.
• ¿Qué pasa con el mapa cuando el dueño borra su cuenta?

Criterios de aceptación

• Un jugador puede crear un mapa propio en el rango reservado
• Sólo el dueño puede editarlo
• Al llegar a la cuota, crear otro mapa devuelve un error claro
• Un mapa de usuario no puede referenciar ni modificar mapas del mundo oficial
• Un mapa en borrador no es visible para otros jugadores
• Tests que cubran el intento de editar el mapa de otro y el de exceder cuota

Archivos relevantes

• frontend/utils/gameLoader.ts (constantes de rango y ruteo por rango)
• api/src/mapas_source/ (estructura de los mapas)

[atiqur-rahman-pro]

Hola @Bitcoindefi!

Excelente propuesta para la arquitectura de mapas de usuario.

Me gustaría trabajar en esta issue para implementar:

1. Reserva del rango de IDs en frontend/utils/gameLoader.ts (ej. 600-1999).
2. Modelo de propiedad y permisos por account_id.
3. Validación de cuotas (límite de mapas por cuenta y densidad de objetos/NPCs) en el backend.
4. Estados del ciclo de vida (draft, proposed, published, archived) e inspección de seguridad económica (deshabilitar drop de oro/XP).

¿Te parece bien que abra un PR dividiendo la implementación o prefieres un único PR con los tests unitarios correspondientes?