Fix generic qf not showing qs from user context on load

[jacbn]

Also adds a few tests to check this in future.

---

In as brief as I can, the user object is sometimes available on load (if you came via soft redirect), and sometimes not (if not). This means our original populateFiltersFromAccountSettings function was not running on soft reload, because the user object had not changed (thus not triggering the useEffect).

I have fixed this by pulling the logic from populateFiltersFromAccountSettings into external functions, which are also used in the initial values for searchStages and searchExamBoards provided the user is available then. This means that no matter when the user is available, we always run the same logic.

[jacbn]

This isn't strictly part of the fix for this PR, but this kills off stale requests before they update state later which fixes a lot of random inconsistency with tests! :)

[codecov]

Codecov Report

❌ Patch coverage is 94.44444% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 42.47%. Comparing base (091a139) to head (bb1666e).
⚠️ Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
src/app/components/pages/QuestionFinder.tsx	94.44%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1936      +/-   ##
==========================================
+ Coverage   42.23%   42.47%   +0.24%     
==========================================
  Files         575      575              
  Lines       24479    24500      +21     
  Branches     8087     8083       -4     
==========================================
+ Hits        10339    10407      +68     
- Misses      13474    14047     +573     
+ Partials      666       46     -620     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sjd210]

These consts are being recalculated on every re-render, so when a filter is changed, the params change and so do these values. In turn, this retriggers the updateFiltersFromAccountSettings useEffect. This is creating some weird effects such as clicking "Clear all filters" resetting filters to account settings rather than actually clearing them.

These should probably be using either a useRef or useMemo so it's truly just initial values on mount (I don't have a strong preference for which - annoyingly we seem to be slightly inconsistent in situations like this across the codebase).

[jacbn]

Ah, yeah, I moved the initial ones into the updateFilters useEffect deps to stop the exhaustive deps warning, but that wasn't stable :/

I'm not sure I ever looked much into when to use which. This was a good read. I think in this case, these values:

• should exist only as the initial ones; never update
• are never used in rendering

so ref makes sense here. A useful side-effect of this is no longer having exhaustive deps warnings around this, which we wouldn't get if we used useMemo (since initialSearchStages is dependent on params.stages, which we would necessarily need to ignore).