[Erry91]

What this changes

Two UI tests fail intermittently since #1493 moved preparing a PDF opened after the first frame
onto the open worker:

• ui::dropping_a_pdf_on_the_window_opens_it failed in 3 of 4 runs of the ui suite on main
  (7437bde), on macOS, and also failed when run alone.
• editing::files_dropped_outside_the_page_grid_still_open_as_documents fails when the
  editing suite is busier. With one unrelated test added to the suite, it failed in 5 of 10
  runs.

Both tests drop a PDF and then check for its tab after three frames. The worker often isn't done
by then. #1493 kept startup and test flows inline ("this also preserves deterministic inline
startup and test flows"), but a drop arrives after the first frame, so these two tests ended up
on the worker.

The tests are about where a drop goes (a tab, not the page grid), not about the worker, which
open_worker_tests.rs covers. So both now set run_inline, the switch documented for
background jobs in tests and already used by several test setups. The drop then opens in the
same frame. This removes the race instead of waiting longer for it, and adds no time to the
suite.

Related: these are two of the UI test failures since #1493 that are listed in #1691. #1681
fixes another one with the same cause.

How you verified it

• cargo fmt --check
• clippy with -D warnings on pdfcraft-ui-egui (--all-targets)
• tests pass on the crate I changed

Before and after, under the same conditions:

Test	Failed before	Failed after
ui::dropping_a_pdf_on_the_window_opens_it (full ui suite)	3 of 4 runs	0 of 6 runs
editing::files_dropped_outside_the_page_grid_still_open_as_documents (full editing suite plus one extra test)	5 of 10 runs	0 of 10 runs

No other test changed result.

[Erry91]

Closing this: #1914 already fixed both tests on main. It waits for the dropped document with support::wait_until and adds stronger assertions, which keeps the open worker covered by these tests. That's a better fix than running them inline, as this PR did. Thanks!