Consider refactoring the structure of the functional tests

Why are we doing this?

#2421 adds some functional browser tests.

There is a fairly common structure to all the tests written so far:

• setup Playwright
• specify coding system and codelist name
• create codelist
• specify the searches and concept selections
• apply those searches and concept selections
• save the codelist
• check the codelist appears on the site
• verify the codelist codes in the "Full list"
• check the downloaded CSV

However, for now, in the absence of more tests, these have been left to a largely duplicated structure. This might be OK and perfectly acceptable considering they are tests.

How will we know when it's done?

We have made a decision not to proceed with this task, or we decide to proceed with this task and create a class that handles the underlying testing, with the test author providing the required values only.

What are we doing?

It might be worthwhile to consider factoring this out into a class that only needs the coding system, codelist name, and searches and concept selections specifying. But it may not depending on what other tests we write, and how generalisable they are.

Further, I also think it might be tidier to refactor where the helper functions go too:

• move the functions like create_codelist() that perform actions into the Navigator
• create a new class that specifically handles "Actions" rather than simple navigations, that uses the Navigator
• move those functions onto the test factory class itself if they are only used by that category of tests (probably unlikely?)

Start by reading the functional browser tests introduced in #2421 and compare their repeated Playwright setup, codelist actions, and verification steps. Decide whether the structure is generalisable enough for an abstraction involving Navigator, Actions, or the test factory; done means documenting the decision or updating the tests and helpers consistently.