Unify TextureImporter and EnvironmentMapImporter into one image-import pipeline

[JeanPhilippeKernel]

Context

While designing TextureImporter as part of the texture pipeline redesign, it became a near-sibling of the existing EnvironmentMapImporter — both exist solely to decode a raster image file and get pixels onto the GPU as a Rendering::Textures::TextureHandle. They ended up as two separate IAssetImporter implementations because their output shape differs (flat 2D upload vs. equirect-to-cubemap conversion + .zenvmap cache artifact), not because the underlying concept is different.

Overlap

• Both claim raster image extensions via CanImport (TextureImporter: png/jpg/jpeg/bmp/tga/gif/psd/pic; EnvironmentMapImporter: hdr/exr) and stay mutually exclusive today only by extension-list discipline between two files — nothing enforces the split beyond convention.
• Both decode via stb_image (stbi_load/stbi_loadf) and route allocations through the same per-worker TLSF slab pattern.
• Both ultimately produce a TextureHandle consumed identically by materials and render passes downstream.
• AssetRegistry::InferTypeFromExtension already classifies every one of these extensions under a single AssetType::TEXTURE — the asset-type model already treats them as the same kind of thing; only the importer layer keeps them apart.

Proposal

Investigate merging both into a single importer (e.g. ImageImporter) that branches internally on extension/spec:

• Flat raster (png/jpg/jpeg/bmp/tga/gif/psd/pic) → direct AssetManager::IngestTexture, mirroring TextureImporter::Import's current body.
• hdr/exr → equirect-to-cubemap cook → .zenvmap cache artifact, mirroring EnvironmentMapImporter::Import's current body.

Benefits:

• One place to maintain image-decode conventions (flip-on-load flag, slab usage, extension list) instead of two.
• "Is this extension a texture" becomes answerable in one file instead of two that must independently stay in sync with AssetRegistry::InferTypeFromExtension.
• Removes the current ambiguity where adding support for a new raster format (e.g. .ktx/.ktx2 once a real decoder exists) requires deciding which of two importer files to touch.

Not urgent — both importers work correctly as-is today; this is a duplication/maintainability cleanup, not a bug.

References

• ZEngine/ZEngine/Importers/TextureImporter.h / .cpp
• ZEngine/ZEngine/Importers/EnvironmentMapImporter.h / .cpp
• ZEngine/ZEngine/Core/VFS/Registry/AssetRegistry.cpp (InferTypeFromExtension)