feat: build chunk mesh data off the main thread (MeshData + Jobs, Physics.BakeMesh)

[nigel-hall-codes]

Parent: #259 (techdesign) — see sdlc/#259/design.md, lever L4. Gated on #446 (profile first — #260 closed without recording numbers).
Reanalyzed 2026-07-04: gate moved #260→#446; note on the ChunkBinReader seam added; approach unchanged.

Why

The import builds mesh geometry on the main thread (BuildMesh: SetVertices/SetTriangles/SetUVs + RecalculateNormals), single-threaded. This is the "parallelism that helps the Unity import" lever.

What

• Build mesh geometry with Mesh.AllocateWritableMeshData() / MeshDataArray + IJobParallelFor/Burst across worker threads, then ApplyAndDisposeWritableMeshData on the main thread.
• Pair with off-thread Physics.BakeMesh (see feat: cut MeshCollider cook cost in import (combine / off-thread / defer) #263 / L3).
• Move .bin read + BitConverter parse to Parallel.For (pure CPU/IO, no Unity API). Note: committed HEAD has a clean seam for this — ChunkBinReader (refactor(unity): extract ChunkBinReader from SFMapImporterWindow #426) — but the local working tree currently reverts refactor(unity): extract ChunkBinReader from SFMapImporterWindow #426–refactor(unity): consolidate SFBuildingTemplates paths and facade-frame math #430 back to inline parsing; resolve that divergence before building on either shape.

⚠ Honest gate

Only pays off if mesh build / collider cook is a large share of import time. If #446 shows SaveAsPrefabAsset or the authoring uploads (#447) dominate, those are not parallelizable this way — prioritize #447/#261/#262/#263 instead. Do not start until #446's numbers justify it.

Done when

Off-thread mesh build + parallel bin parsing measurably reduce cold-import time (per #446) with identical resulting meshes.