utilityLayerScene.executeWhenReady never fires (silent hang; blocks validation test idx 170)

### Summary

`Scene.executeWhenReady` on a `UtilityLayerRenderer`'s `utilityLayerScene` never fires on Babylon Native, silently. Any content that waits on it hangs forever with no error, no console output, and no stderr.

This is what keeps Playground validation test idx 170 "Nested BBG" (`#ZG0C8B#12`) excluded, and it is independent of any in-flight rendering work.

### Repro

Snippet https://snippet.babylonjs.com/ZG0C8B/12. It loads `scenes/Alien/Alien.gltf`, attaches a `BoundingBoxGizmo`, then drives frames manually and waits for the gizmo's utility layer to become ready:

```js
const id = setInterval(() => { engine.beginFrame(); scene.render(); engine.endFrame(); });
gizmo.gizmoLayer.utilityLayerScene.executeWhenReady(() => { clearInterval(id); resolve(scene); });
```

The `clearInterval` is the loop's only exit.

From the Playground validation app:

```
Playground.exe --headless --include-excluded --test-index=170 app:///Scripts/validation_native.js
```

> Note: use `--test-index=170`, not `--test="Nested BBG"`. Two tests share that title — idx 24 is enabled and passes in ~2s, and since `--test=` is a substring match, filtering by title silently measures the wrong one.

### Observed

The callback never runs. The scene renders correctly and at full speed the entire time — instrumented over 90s: **~7,600 presents (~84 fps)**. So this is not a deadlock, a stall, or a slow-progress problem. It is a readiness predicate that never becomes true, in a process that is otherwise completely healthy.

The silence is the worst part: nothing on stdout, nothing on stderr, no JS error. The only symptom is that the app never exits.

### Expected

`executeWhenReady` fires once the utility layer scene's resources are ready, as it does on Babylon.js in the browser for the same snippet.

### Why it is not visible today

On current master this test is masked by an unrelated failure: the same content exhausts the bgfx view counter and throws `Error: Too many views` after ~18s, which tears the `setInterval` loop down and produces a fast, if misleading, failure.

With the view-exhaustion fix in #1805 the throw no longer happens, so the underlying hang is exposed. #1805 does not cause this and does not fix it — idx 170 stays excluded there. Filing separately so the readiness bug can be fixed on its own.

Worth checking whether this affects other gizmo / `UtilityLayerRenderer` content, since nothing about the failure looks specific to `BoundingBoxGizmo`.

### Environment

Win32, D3D11, RelWithDebInfo, base `03c4d965`.

Reproduce Playground validation test idx 170, "Nested BBG," with `Playground.exe --headless --include-excluded --test-index=170 app:///Scripts/validation_native.js`. Trace `Scene.executeWhenReady` on `gizmo.gizmoLayer.utilityLayerScene` while inspecting the `UtilityLayerRenderer` readiness path. Done means the callback fires and the validation app exits successfully without the silent hang.

Written by the indexing model from the issue text.