Flaky test: native touch page hold under a loaded parallel run #8

shell::fields::tests::pages_tests::native_touch_page_hold_distinguishes_menu_reorder_and_scrolling fails now and then when the whole suite runs in parallel on a loaded machine; it passes alone, with its module, and in CI so far.

Failure (macOS, Rust 1.99, cargo test --workspace, about one run in three under load):

panicked at crates/ferrodesign-app/src/shell/pages_tests.rs:431:5:
assertion failed: s.has_page_drag()

The test holds a page row with a touch (touch_begin, then a sleep of hold_wait_duration().max(350 ms) + 30 ms and Dispatcher::ui_thread().run_jobs(None)), moves the touch to another row and expects the page drag to be active. The drag decides that a touch is a hold from wall-clock time (PageDrag::is_touch_hold, started.elapsed() >= hold_after in shell/page_drag.rs), and headless input is stamped with wall-clock time as well, so the outcome depends on scheduling under load.

The page rename test had the same kind of failure (a double click split by the 500 ms double-tap window); #7 fixed it by giving the test fixture platform settings with a 5 s double-tap window. This one needs a look at the hold path: which condition fails under load (the drag never created, created inactive, or replaced by the viewport's touch scrolling), and then a deterministic way to drive it, for example a test clock for the hold or driving the hold from the fixture's settings rather than real elapsed time.