feat(engine): support map background colour

[JumpLink]

Problem

The mass-ported OoT2D-2014 maps (#212) showed a hard render defect: large void areas and 'strange artifacts'. Root cause: the original .zmap format carries a per-room background colour in its header — the 2014 game fills the whole screen with it before painting tiles, so sparse maps (Field stores tiles for only ~19% of its 372×380 cells) rely on it for the grass/floor. Our converter dropped it.

Changes

• MapData.backgroundColor — optional #rrggbb, documented as a fill below all tile layers.
• Engine: loadMap maps it onto the Excalibur GL clear colour (reset to transparent for maps without one). A colour Actor was tried first but goes through Excalibur's Rectangle Raster (2D-canvas rasterise + texture upload) — the clear colour is pure GL and matches the original game's fill-the-screen semantic.
• MapPreview: fills the map bounds with the colour in both the direct paint and the baked texture — atlas cards + welcome thumbnails now show the real room colours.
• Data: backgroundColor injected into all 19 games/oot2d-2014 maps from their zmap headers (exporter updated in PixelRPG/oot-2d@e3ea382; values range from Field's grass #409740 to SMB's classic sky #5C94FC).

Verification

• Atlas previews verified visually (Field/Castle/Guards green, Deku brown, Lost Woods olive — matches the reference renders from tools/export-maps.py).
• @pixelrpg/engine check + 748 tests green, @pixelrpg/gjs check green.
• Engine-scene visual check pending a stable GL init — the intermittent engine-init segfault (pre-existing, see TODO) fired repeatedly during validation before any map code ran (Loading map: never logged), so it is unrelated to this change.