Cooked assets and streaming

crates/assets (tassix_assets): imported models (nodes, meshes, materials, textures with shared images) and decoded images are written as rkyv archives behind a small header (magic, cook version, kind), and read back from memory-mapped files with validation, copying the arrays straight out (no parsing or decoding).
The asset cache (TASSIX_ASSET_CACHE, default %LOCALAPPDATA%\Tassix\AssetCache, off disables it): models are keyed by path and record their source files (the model and the external buffers or textures it read, by size and modification time), so a change re-imports; images are keyed by a hash of their encoded bytes. Cooked files are written to a temporary name and renamed into place. model_load and image_decode go through it, so glTFast, Resources.Load, Unity project models and scene textures all use it.
Streaming: tassix_assets::Streamer loads models on background threads; Resources.LoadAsync (with ResourceRequest) starts one for a model and creates its assets on the main thread when it completes, at the start of a later frame. Reading asset early loads it now, but the request still completes with the frame, as Unity's does (the new resources_async scenario matches Unity; 46 scenarios pass). The car showroom sample streams its models.
Measured (release, cargo run -p tassix_assets --example load_times): a 231 KiB glTF character 2.45 ms imported vs 0.42 ms cooked, a 143 KiB FBX 3.60 vs 0.43 ms, a 2048x2048 PNG 38.3 vs 5.75 ms.
Not yet: compressed cooked files (zstd/LZ4) and GPU texture formats (BCn) with precomputed mips, streaming texture mips by distance, cooking Unity projects ahead of time (a cook command), async glTFast loads.
Next: agent avoidance, then Sprite (cookie) lights and soft 2D shadows.