[ui] Wire js_gc_step_us into UI run loops — GC pauses currently land mid-frame on the main thread

[proggeramlug]

Problem

perry-ui hosts have no idle-time GC integration: collections land on the AppKit/UIKit main thread mid-frame.

• The macOS app drives JS via an ~8 ms main-thread NSTimer pump calling js_promise_run_microtasks() (perry-ui-macos/src/app.rs:565-575, 1224-1291); the pump tail runs the moving safepoint minor (promise/microtasks.rs:781-794).
• Any allocating widget callback can hit the alloc-point synchronous minor.
• A fallback minor of 300 ms+ freezes the UI for 20-40 frames; nothing consults frame deadlines, CADisplayLink idle time, or NSRunLoop activity.
• The budgeted embedder stepper already exists — js_gc_step_us (gc/policy.rs:1834-1848) is a true time-boxed host API — but nothing wires it to the run loop.

Proposed fix

Expose js_gc_step_us to the UI pumps with a per-tick microbudget (e.g. spend idle time up to the next frame deadline), and gate the pump-boundary moving minor on remaining frame budget. Same pattern applies to perry-ui-ios/tvos/watchos hosts.

Context

2026-07-09 GC audit (platform-fit + pause dimensions). Depends partly on the incremental-GC graduation issue for the stepper to make real progress.

[proggeramlug]

macOS half DONE (#6198, merged): the ~8ms NSTimer pump now spends up to 2ms/tick in js_gc_step_us at the (precise-root) pump boundary. Remaining (this issue): CADisplayLink-aligned budgets on macOS, and the iOS/tvOS/watchOS/visionOS host pumps (same one-line js_gc_step_us call in each host's run-loop pump).

[proggeramlug]

Shipped across two PRs: #6198 wired js_gc_step_us into the macOS pump at the frame boundary; #6210 extended the same pump-step wiring to iOS/tvOS/watchOS/visionOS + the remaining hosts. With #6226/#6235/#6239, those pump steps now drive a sound, paced, census-free budgeted collector. Remaining pause-quality work (WeakProcessing slicing, scanner budgeting) is tracked in #6180.