Fix flaky work package activity journal filter spec

[myabc]

Stabilises spec/features/activities/work_package/activities_spec.rb[1:5:2:1] and [1:5:2:2] ("filters the activities based on type" / "resets an only_changes filter if a comment is added by the user"), the most frequently reported flaky feature spec in CI over the last 24h (10 hits).

Root cause

The activity tab auto-polls every 10s, and update_attributes arms an extra poll ~2s later. Each poll re-fetches and re-renders the whole journals list, reading the active filter at request time.

The shared helper filter_journals wrapped its menu clicks in a single wait_for_turbo_stream, which resolves on the first op:turbo-stream-rendered event. A concurrent polling stream can satisfy that wait before the filter's own stream renders, so the helper returned while the DOM still showed the previous filter — and the absence assertions that follow (expect_no_journal_changed_attribute, expect_no_journal_notes) then raced a late render.

Fix

After the menu interaction, block until the journals wrapper actually reflects the requested filter via its op-wp-journals-<filter>-<sorting> test selector — the same deterministic post-condition set_journal_sorting already uses. This waits through any stale poll render until the correct filter lands.

Spec-only change; no production code touched.

Verification

• script/bulk_run_rspec spec/features/activities/work_package/activities_spec.rb --run-count 20 (pending — relying on CI)

Known limitation / follow-up (separate PR, not in scope)

[1:5:2:2] exercises a genuine production race: polling.controller.ts updateActivitiesList has no AbortController/generation guard, so a poll response captured under the old filter can be applied after the filter changed (a stale only_changes poll can re-remove a freshly added comment). The helper change reduces but may not fully close [1:5:2:2]. A complete fix discards/aborts poll responses whose requested filter/sortBy no longer match the current outlet values; tracked separately.

[Copilot]

Pull request overview

This PR stabilizes flaky feature specs around the Work Package activity journal filter by making the filter_journals helper wait for a deterministic DOM post-condition (the journals wrapper reflecting the requested filter/sorting) instead of relying on the first Turbo stream event, which can be satisfied by concurrent polling updates.

Changes:

• Extend filter_journals to accept an optional sorting: keyword (default :asc) so it can wait for the precise wrapper selector.
• After triggering the filter change, wait until op-wp-journals-<filter>-<sorting> is present, mirroring the deterministic pattern already used by set_journal_sorting.