Bump gpui-pre to 0.3.8

[madcodelife]

What

• Bump the pinned gpui-pre / gpui-pre-wgpu / gpui-pre-reqwest-client deps (lib + example) from =0.3.7 to =0.3.8, the same way Bump gpui-pre to 0.3.7 #21 did the previous bump.
• Move the example's gpui-kit rev from 2ec5696 (on gpui-pre 0.3.7) to v0.7.1 (87d10ae, on gpui-pre 0.3.8).
• Fill the two fields gpui-pre 0.3.8 added to RequestFrameOptions. Without them the Android build fails with E0063: missing fields signal_at and signal_source.

The new fields

signal_at is when the platform first asked for the frame, before main-thread dispatch (None if unknown). signal_source says whether the request came from the OS (NativeCallback) or from the backend's own scheduling: a timer, retry, or fallback sleep (LocalSchedule). GPUI's frame profiler uses them to measure how long a frame request waits before it is handled. The desktop backends capture the timestamp only with GPUI's profiler feature on, through PlatformFrameSignal, and they use the OS vsync time where they have one (the CVDisplayLink timestamp, the Wayland frame-callback time).

• Android: FramePacer now records why each frame became due:

  • a vsync is a NativeCallback, stamped with the AChoreographer frame time. The vsync thread converts that time from CLOCK_MONOTONIC to an Instant and hands it to the loop through a PlatformFrameSignal, so the conversion only runs when profiling. It falls back to the callback's arrival time if the timestamp is implausible, for example when a 32-bit long truncates it.
  • demand served at once (the first frame after idle, or a frame that overran the interval) is a LocalSchedule, stamped when the pacer let it through.
  • a frame paced by the fallback clock is a LocalSchedule, stamped with the deadline it waited for.

  The window's frame callback drains this through frame_source::take_signal. If a frame stays owed, it keeps its first request time. take_signal deliberately does not pull in a vsync that arrived in the meantime, because that vsync belongs to the next frame.

• iOS: gpui_ios_request_frame is called from the host's CADisplayLink callback. It reports a NativeCallback stamped on entry, which mirrors the macOS display_layer path.

No other 0.3.7 → 0.3.8 API change affects the mobile layers. The new Platform methods (request_windowing, set_initial_windowing, set_activation_policy, graphical_environment) all have default implementations.

Verified

• cargo check --all-targets, cargo test --lib (50 passed, including new FramePacer signal tests) and cargo fmt --all -- --check on the host
• cargo check --target aarch64-apple-ios / aarch64-apple-ios-sim / aarch64-linux-android, for the lib and for the example
• cargo check with --features gpui/profiler for aarch64-apple-ios-sim and aarch64-linux-android
• cargo build --lib --target aarch64-linux-android for the example (links with NDK r27c)
• cargo clippy reports nothing new; the warnings it already reported are unchanged and none are on changed lines

🤖 Generated with Claude Code

[madcodelife]

Duplicate of #27