Flaky test resolution

[h-m-m]

What github issue is this PR for, if any?

This fixes some flaky tests.

• Fixes one that was listed as TODO in a comment
• Fixes a few tests that we noticed in local dev envs at the RfG 2025 events

This also speeds up test times for spec/system/casa_cases/edit_spec.rb

What changed, and why?

This addresses two main types of changes

• When expecting a controller to do something via a headless browser actions, assert a UI change you expect to see before asserting the DB was updated or navigating the browser to a different page
  • On fast machines, it's possible to navigate away before the browser has finished sending its request
  • In many of these cases, the visit call was unneeded because the page to visit was already the page that the controller redirects to
• When asserting in sequence a series of page content matchers (CSS based or otherwise) are valid and not expecting the page to change between assertions, put at least one positive .to assertions before any .not_to assertions whenever practicable.
  • If the negative page content matchers are first, Capybara would wait for the full length of its maximum wait time to be extra sure the content doesn't show up at the very last second
  • Getting this wrong can easily double the time Capybara waits to make sure the page is correct before passing the test.

Using expect(page).to have_current_path(expected_path) does count as putting a positive assertion first that helps with not doubling the wait time . The have_current_path matcher was intentionally written with this goal in mind.

How is this tested? (please write rspec and jest tests!) 💖💪

I tested it locally repeatedly and the edited tests pass reliably.

Feelings gif (optional)

[compwron]

@claude fix merge conflicts?