ifcviewer-web: fix two streaming stalls found in battle testing

driveStreamingLoads could deadlock: a chunk waiting on asynchronous
pool growth parks in a frame-counted backoff cooldown, but once the
render loop quiesced after the settle burst the frame index froze, so
the cooldown never expired and streaming stalled part-loaded until the
user moved the camera. Keep the loop alive while growth may still land
(growth_pending() || can_grow()), exposed via a new BufferPool accessor.

loadSidecarMetadataWeb put the model in the scene before reading the
element-metadata block header, leaving a window where the locator was
still zero. A getObjects() landing in that window could not distinguish
"locator not read yet" from "sidecar has no element block" and latched
the model as permanently empty. Read the 16-byte header first, then
apply; carry the locator through applyCachedModel so it is set before
any web element-metadata fetch can run.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

src/ifcviewer/BufferPool.h

@@ -115,6 +115,12 @@ public:
                 || total_capacity_bytes() < max_total_capacity_bytes_);
     }
 
+    // Whether a growth is in flight. On web that window is real time — a
+    // provisional sub-buffer validates asynchronously a frame or two later — so
+    // the streaming driver has to know that free space is still on its way and
+    // that a chunk it just parked is waiting on something that WILL arrive.
+    bool     growth_pending() const { return growth_pending_; }
+
     // Hard ceiling on total pool capacity (0 = unlimited). Once total capacity
     // reaches this, can_grow() returns false so the streaming driver EVICTS
     // instead of growing. Critical on web: a growth past the wasm heap ceiling