bake_use_thread_pool is a no-op; mesh merge always runs on the main thread

[saworbit]

Context

LevelRoot.bake_use_thread_pool defaults to true, is persisted in .hflevel settings, and is forwarded into baker options. Bake time estimates even recommend it:

# addons/hammerforge/systems/hf_bake_system.gd (~266)
elif count > 200:
    tip = "Consider enabling thread pool for faster bakes"

Problem

Baker._merge_entries() takes _use_thread_pool and never uses it:

# addons/hammerforge/baker.gd (~598)
func _merge_entries(entries: Array, _use_thread_pool: bool) -> ArrayMesh:
    var mesh_entries = _collect_mesh_entries(entries)
    if mesh_entries.is_empty():
        return null
    return _merge_entries_worker(mesh_entries)

Mesh merge, surface grouping, and vertex transforms therefore always run on the editor/game thread. The Inspector checkbox and the ">200 brushes" tip are misleading.

This is separate from #28 (cache the wireframe shader; batch face-group vertex transforms).

Proposed solution

• When use_thread_pool is true and surface count is above a small threshold, run _merge_entries_worker via WorkerThreadPool.add_task and await from the bake coroutine (bake already awaits two process frames for CSG).
• Keep a synchronous fallback for tests / use_thread_pool == false.
• Do not touch ArrayMesh / RenderingServer from the worker if that is unsafe in 4.7 — build PackedArrays on the worker and assemble the ArrayMesh on the main thread.
• Drop or rewrite the estimate tip so it only appears when the pool is actually used.

Acceptance

• A merged bake of a 200+ brush stress scene spends merge time off the main thread (profiler).
• Disabling the flag restores the current synchronous path.
• Existing baker tests still pass.

[saworbit]

Fixed in 61fed6f.

Baker._merge_entries() now honors use_thread_pool. Surface grouping and vertex transforms run on WorkerThreadPool; ArrayMesh assembly stays on the main thread. Sync and pooled merges produce the same surface/vertex counts. The ">200 brushes" bake tip only appears when the pool is off.

[saworbit]

This still blocks the editor thread. Baker._merge_entries() in addons/hammerforge/baker.gd starts a worker task and immediately calls WorkerThreadPool.wait_for_task_completion() at line 634. The PackedArray work runs on a worker, but the bake caller cannot yield or process a frame until it finishes. This misses the issue acceptance case for keeping merge time off the editor thread. Reopening. Await completion from the bake coroutine and return to the main thread only for ArrayMesh assembly.

[saworbit]

Fixed in 61fed6f. The merge path now honors bake_use_thread_pool and keeps the synchronous fallback. The pooled and synchronous mesh results match in the baker regression test.