Fix flaky drag/reorder examples in issue_ordering_spec

What does this MR do and why?

Fix flaky drag/reorder examples in issue_ordering_spec

This spec was flagged as a top pipeline-blocking flaky test file, with 10 blocked pipelines and 11 job failures between Aug 11 and Aug 21, 2026. Both root causes traced back to Capybara finders that do not wait, which race against Vue's async rendering of board lists and cards.

The drag helper called all('.board-list') without a count expectation, so Capybara returned immediately instead of retrying. Since before blocks only wait for the board column shells, and the list itself stays hidden behind v-show="!loading" until ready, all could come back empty or short, causing a nil error when indexing into it. Passing a minimum: expectation makes it wait for the lists and cards to actually be visible. Separately, assertions like expect(all('.board-card').last).to have_content grabbed a stale element before the drag re-rendered the list, then waited on that same stale reference and timed out. Switching to expect(page).to have_selector('.board-card:last-child', text:) uses a waiting finder instead. This follows the same pattern already applied to the "move to position" examples in commit be3482d6, which never got extended to the drag-based examples, where the remaining failures were concentrated.

All 15 examples pass locally

Tracking issue: https://gitlab.com/gitlab-org/quality/test-failure-issues/-/work_items/44257

References

• https://gitlab.com/gitlab-org/quality/test-failure-issues/-/work_items/44257

Screenshots or screen recordings

Not provided

How to set up and validate locally

for i in $(seq 10); do RAILS_ENV=test bundle exec rspec spec/features/boards/issue_ordering_spec.rb --order rand || { echo "FAILED on run $i"; break; }; done

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.