fps: Leave the readout clock's own frame out of the readings

[madcodelife]

Summary

The HUD's readout clock dirties the window every 500ms to move its digits. To GPUI that is an invalidation like any other — the window is drawn in full and the frame trace records the draw — and the sampler then counted that draw as one of the application's frames. On a window with nothing to redraw it is a cold frame every 500ms feeding FRAME, P95, DROP and MAX; idle, it can be half the samples.

#2954 stopped the HUD from driving the frame loop. This is the one frame it still causes, and until now it was measured as if the application had asked for it.

Changes

• FrameSampler::expect_own_frame(at) — the clock announces each notify before it lands. The first draw whose draw_start >= at is the one that answered it; if its invalidations count is no more than the clock's unanswered notifies, the HUD was the only thing that wanted that frame and it is not sampled. Coalesced with an invalidation of the application's own, it stays — the work was wanted, so the cost counts.
• Notifies are counted, not flagged. A window the platform is not drawing — occluded, minimized — accumulates one per tick, and the draw that finally answers carries all of them; a boolean would have read that draw as the application's.
• Presents are untouched. FPS and INTERVAL still count the HUD's frame among what reached the screen, which it did.
• Docs. website/docs/fps.md (+ zh-CN) say so under What the HUD itself costs. crates/fps/README.md is brought in line with the HUD as it is since fps: Sustain frames by default, and stop grading the rate #2944 / fps: Derive the headline rate from frame cost instead of driving the frame loop #2954 / fps: Cap the headline by asking the platform what the panel runs at #2956: the .continuous(true) example no longer compiled, the ### continuous section described a removed option, and two notes still explained the rate grading those PRs took out. The INV row's comment loses its continuous reasoning too.

Why invalidations is the right test: WindowInvalidator::record_frame_dirty increments on every notify, not on the clean→dirty transition, so "the clock's notifies were the only invalidations this frame carried" is exactly invalidations <= notifies.

Test plan

• cargo test -p gpui-fps — 29 pass, 4 new: the draw answering the clock is not a sample; a frame the application also asked for stays; a frame drawn before the tick is the application's; several unanswered ticks are still one frame of the HUD's
• cargo clippy -p gpui-fps --all-targets -- -D warnings, cargo fmt --check
• Window idle: FRAME / MAX stop moving at the clock's 500ms cadence; scrolling reads as before