[xunguangzlj-cloud]

Fixes #5603

What

A rejected window.__hf.buildReady hold is now a named build failure: the runtime records it on the startup-error channel (recordStartupError → window.__hfStartupError), so capture's waitForRuntimeReady throws with the composition's own rejection reason and the render fails non-zero — instead of treating the hold as released, rendering every frame of a scene that never built, and exiting 0.

Why

From #5603: the runtime waited on buildReady promises through createSettledTracker, whose rejection path marked the wait settled and swallow()ed the reason. Check reported 0 errors and render exited 0 with empty frames; the rejection reason was invisible (debug-only via __hfDebug). A pipeline that trusts the exit code ships a broken film.

How

One branch: the isBuildReadinessSettled tracker's rejection callback now calls recordStartupError(err) (the existing named channel, already used by the start-up failure path at init.ts and consumed by captureCompositionFrame.ts's waitForRuntimeReady, which throws when __hfStartupError is set) before the existing swallow (kept, so Studio's __hf.onSwallowed collectors still see the event). Resolve semantics are untouched: holds that resolve still release the wait exactly as before, and the stale-registry teardown behavior is unchanged.

Test

fails without the fix: pnpm vitest run src/runtime/init.test.ts -t "buildReady" — "names a rejected buildReady hold on the startup-error channel instead of releasing silently (#5603)" asserts window.__hfStartupError names the rejection; on main it stays undefined (the release path) and the test fails.

• pnpm vitest run src/runtime/init.test.ts -t "buildReady": 4 passed (was 3 passed / 1 failed on main); the sibling resolve/teardown buildReady tests are untouched.
• pnpm vitest run src/runtime/init.test.ts: whole family passes (268 tests).
• tsc --noEmit -p tsconfig.runtime.json clean; oxlint on both files clean.

[xunguangzlj-cloud]

Closing — #5746's channel now does what this PR did: a rejected build hold records its reason () and surfaces it through the same comparison my change targeted, so capture fails with the reason instead of silently rendering empty frames. Happy to see the scenario covered by the maintainer's own implementation; nothing left to merge here.

[xunguangzlj-cloud]

Corrections to my own note above (the shell ate the backticks): the channel is BuildReadyRejection / recordBuildReadyRejection, and the comparison target is window.__hfStartupError.