fix(world): build per-zone Lua VM in the zone process

[Taure]

Problem

game.zone.spawn (and zone-based game.spatial / game.terrain) silently did nothing from Lua on lazy and snapshot-recovered zones - in fact all per-zone Lua (zone_tick, handle_input) was dead there. The per-zone Luerl VM was only ever stitched in on the pre-spawned path, and a VM (opaque closures) can't survive a jsonb snapshot. Large worlds (grid_size > 100 defaults to lazy) and persistent worlds were affected.

Fix

Implements the new optional asobi_world callbacks from widgrensit/asobi#131:

• init_zone_state/2 builds the zone's Luerl VM in the zone process (handle_continue), so it binds zone_pid => self() and match_pid => world_server_pid. Covers every creation path uniformly - pre-spawned, lazy, recovered. Re-encodes gameplay state restored from a snapshot.
• dump_zone_state/1 decodes the Luerl game_state ref to a plain, jsonb-safe map (or null when never seeded, so a script's game_state == nil init guard still fires after recovery) and drops the VM.

generate_world no longer injects per-zone VMs; it returns plain zone states and each zone builds its own.

Depends on widgrensit/asobi#131 (merged); pinned via rebar.lock.

Tests

New asobi_lua_zone_spawn_tests:

• init_zone_state builds a VM from an empty (lazy) zone_state.
• gameplay state round-trips through dump_zone_state -> jsonb -> init_zone_state.
• a never-seeded zone round-trips as nil, not an empty table.
• dump_zone_state without a VM stays jsonb-safe (degraded path).
• end-to-end: game.zone.spawn from Lua reaches a live asobi_zone built purely via handle_continue.

Existing world/resource-limit/property suites migrated to the new init_zone_state/2 contract. Full suite: 223 eunit, 0 failures.

Follow-up (separate)

widgrensit/asobi#132 - lazy-reaped zones don't reload their DB snapshot on respawn, so their gameplay state doesn't round-trip yet (eager persistent worlds do).