fix(host): await shared renderer readiness before widget launch

[SunkenInTime]

Widget workers can start before the shared renderer accepts its first handshake. A supported canvas then falls back to software, and Native SDK's stable-pixel fallback can keep it there after the renderer becomes available. Wait for a valid renderer hello reply before launching fresh or replacement workers.

The host polls without blocking its supervision loop, keeps pending widgets in their existing starting/backoff state without consuming restart attempts, and resets readiness when its renderer exits. It releases the probe's session rights immediately and uses the pinned Native SDK protocol header; no SDK code changes. The renderer process also explicitly clears the inherited client-renderer flag so it can initialize its own Metal backend.

Reproduction and validation:

• Current default branch 85fda8c: delay only the renderer executable by one second, then run the unchanged supported synthetic widget. Worker logs show the renderer initially unavailable, a later connection, and permanent backend=software reason=shared-pixel-stable retry_ms=none. Waiting for readiness before worker exec keeps the same widget on GPU.
• Focused supervision regression before the fix: 60 passed, 9 skipped, 1 failed (expected starting, found backoff). After the fix: 62 passed, 9 skipped. The new Mach fixture proves that service registration alone does not unlock launches, a valid hello does, malformed replies fail, and accepted/rejected/cancelled probes release their rights. A saturated-queue regression also failed before reply-right cleanup (61 passed, 9 skipped, 1 failed) and now passes without changing the process's port-name count. Supervision coverage includes pending status/reason, launch after readiness, invalidation after a missing/reaped renderer, replacement waiting, and the automation bypass.
• DEVELOPER_DIR=/Library/Developer/CommandLineTools zig build test -Doptimize=ReleaseFast --sysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --summary all in host: passed. The corresponding production build passed all 14 steps; codesign --verify --deep --strict zig-out/Weaverd.app, Zig formatting, and git diff --check passed.
• Parent workflow retest at exact head f78ffa3: the original one-second renderer delay, no external launch gate and no DYLD injection, now stays on GPU. Host logs record waiting followed by readiness; worker logs show a connection without the permanent software latch. On this M5 Pro/macOS 27 run, one 15-second sample after five seconds of warmup measured 9.260% total CPU, versus 64.576% in the original software repro. The earlier e28fba8 candidate also passed (8.042%). These are illustrative single samples under changing desktop load; the backend correction is the decisive result.
• Local reproduction and raw receipts: /tmp/weaver-startup-repro-20260924/run.py, /tmp/weaver-startup-repro-20260924/run_fixed_final.py, /tmp/weaver-startup-repro-20260924/receipts/fixed-final-f78ffa3-delayed-renderer-gate0-r1/, and /tmp/weaver-readiness-{queue-red,final-tests,final-build}.log.

Existing workers keep their state during renderer restarts. An already-running worker can still latch software during an outage or a later packet/presentation refusal, including with a live renderer; restoring GPU in those cases needs a separate Native SDK recovery change. This repair addresses the cold-start trigger by gating new launches, without forcing worker restarts or introducing a startup timeout.

Current-head CI and review: all seven platform jobs passed in run 36066803462, including the macOS host build and Mach fixtures. Greptile reviewed f78ffa3 twice, reported no reproduced code defect and no review threads, but its check remains failed (3/5) because its T-Rex worker is Linux and cannot execute native macOS tests. The follow-up supplies the passing hosted macOS job, local red/green tests, and original-workflow retest. This is an unresolved reviewer-infrastructure limitation, not a claim of an all-green review. No required status checks or branch protection are configured; the PR remains open and unmerged.

[SunkenInTime]

@greptile please review the latest head f78ffa3. Follow-up adds failed-send reply-right cleanup with a red/green saturated-queue regression, plus missing-renderer readiness invalidation coverage. Local host tests/build pass; no Native SDK code changed.

[greptile-apps]

Confidence Score: 3/5

The readiness controls are implemented consistently and no broken user flow was reproduced, but native macOS behavior still requires execution on a supported machine.

What we checked:

• Premature widget launch: The launch path continues without calling self.launch while renderer readiness is false. Readiness becomes true only when the Mach hello poll returns the ready result after validating the renderer reply.
• Stale readiness after renderer exit: Renderer reaping removes the child marker, clears the process handle, and resets readiness before the loop supervises widgets. The reset clears both the probe receive right and the ready flag.
• Blocking renderer readiness probe: The send and receive operations use zero-timeout Mach flags. A timed-out send or receive maps to the waiting state, allowing supervision to resume instead of waiting for renderer startup.
• Readiness-probe Mach-right leak: Reset releases the temporary receive right, and every received reply is destroyed after validation to release its transferred session right. Focused ownership assertions passed for completed, rejected, and failed-send cleanup paths.
• Reviewed the non-automation launch gate and renderer hello validation path.
• Traced renderer reaping through readiness reset and widget supervision, and observed that host readiness is cleared before a replacement widget can be admitted; the Linux gate blocked the macOS fixture from running, while the focused regression path and source ordering were captured.
• Ran the requested verification; T-Rex reported that the verification ran but local artifact references were not uploaded.

Summary

This change prevents macOS widgets from launching until the shared renderer has returned a valid handshake response. It also clears renderer readiness after exit, polls Mach IPC without waiting on a full queue, and cleans up temporary Mach rights.

The reviewed paths show that non-automation widgets remain pending before renderer readiness, replacement widgets are blocked after renderer exit, saturated queues return immediately, and completed or failed probes release their temporary rights.

T-Rex validation blocked

The native macOS host and Mach IPC fixture could not run because the available worker is Linux and lacks the macOS SDK, Mach runtime, xcrun, and xcodebuild. The host build intentionally stops before compiling tests on unsupported platforms. Configure VMs

_{Reviews (2) · Last reviewed commit: "fix(host): release readiness reply right..."}

[SunkenInTime]

@greptileai Please re-review exact head f78ffa3b5818320846248117bfa0208ba5b92d3a using the macOS execution evidence below. The latest summary reports no reproduced code defect, but the check failed because T-Rex's Linux runner lacks Mach/macOS tooling. The native paths were executed separately on both hosted and local macOS:

• Current-head macOS headless CI job passed, including its Build and test macOS host step. This runs the real Mach readiness fixture and host supervision tests. All seven platform jobs in the same exact-head run passed.
• Local Apple M5 Pro/macOS 27/Zig 0.16: the saturated-queue fixture was first run against the implementation without the reply-right cleanup and failed at port_name_count() == before (61 passed, 9 skipped, 1 failed). With the cleanup at this head, the same suite passed (62 passed, 9 skipped). The full production build passed 14/14 steps, with signature verification successful. Local commands are retained in the PR description.
• The original workflow was rerun at this exact head: delay only renderer exec by one second, run the unchanged production widget/runtime, with no external readiness gate and no DYLD injection. Host logs show widgets wait for its readiness reply, then widget launches enabled; the worker connects and stays on GPU. The original host permanently selected software under the same delay. The parent investigator independently ran and inspected this retest.

The T-Rex Linux execution limit is valid as a limit on that runner, but it does not mean macOS execution remains unperformed. Please assess the code and current macOS receipts, and identify any remaining actionable defect. Existing-worker fallback recovery remains explicitly outside this startup-only repair.