The existing fix in eclipse/master (commit 87352d6f36) added a
waitForDialogRefresh() method but used a fixed-time wait (3 × 50ms = 150ms)
which was still insufficient on slower systems like macOS CI, causing
intermittent failures.

Root cause:
- FilteredResourcesSelectionDialog performs async operations (FilterHistoryJob
  → FilterJob → RefreshCacheJob → RefreshJob) after refresh()
- These jobs populate the table and apply initial selections asynchronously
- The original fix waited only 150ms, which is not enough on slow machines
- This caused the test to check selection before it was applied, resulting in:
  "expected:<[L/.../foo.txt]> but was:<[]>"

Improved fix:
- Changed waitForDialogRefresh() to use DisplayHelper.waitForCondition()
- Wait up to 2 seconds for table to be populated (condition-based, returns
  immediately when items appear)
- Then wait additional 250ms (5 × 50ms) for selection to be applied
- Total: condition-based wait + 250ms vs previous fixed 150ms
- Faster on fast systems (condition returns immediately when table populates)
- More reliable on slow systems (up to 2 seconds for table population)

This approach:
- Uses condition-based waiting for table population (more efficient)
- Provides adequate time for selection to be applied (250ms vs 150ms)
- Works reliably on both fast and slow systems
- Test time: ~9 seconds vs ~16 seconds with longer fixed waits

Verified with multiple consecutive test runs - all passed consistently.

Builds on the fix from commit 87352d6f36 which already added
waitForDialogRefresh() to the appropriate tests.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>