UI state not updated after orphan code removal in `update_code_statuses` action

Why are we doing this?

#3206 Identified an issue whereby certain user actions would result in a codelist becoming empty in a surprising manner. This was found to be due to behaviour introduced in #2532 to resolve a bug regarding orphan codes (those without related search terms or [ex|im]plicit inclusions) causing a broken builder in certain circumstances.

Unfortunately it was implemented in such a way that changes would be made to the backend state (the removal of orphan codes) which were not reflected in the frontend state. This resulted in codes being available for inclusion in the frontend which had already been completely removed from the codelist in the backend and so any user attempt to include them silently failed and only became apparent when the user saved the codelist or refreshed the page, whereupon they would disappear. This particular behaviour has been partially remediated by #3209 which allows for previously-deleted codes to be "re-included".

Additional to this issue of state synchronisation, there are open question regarding whether removal of these "orphan codes" is correct in all circumstances. This is particularly questionable when the codelist in question was initially created by uploading a csv and therefore every code within it has no associated searches.

This comment contains a deeper explanation of the issue and the questions of what the correct behaviour should be.

How will we know when it's done?

1. The codelist state in the UI is an accurate reflection of the backend state at all times
2. We understand what the correct behaviour regarding orphan code deletion is
3. OpenCodelists implements this correct behaviour

What are we doing?

• Ascertaining what the behaviour of the update_code_statuses action is with uploaded and search-created codelists and various sequences of user actions ( see #3206 for examples of user action sequences that can reveal problems)
• Analyse what should be the correct behaviour of this action with respect to orphan codes - this should consider what reasonable user expectations are, and should also ensure that the broken state fixed in #2532 is not reintroduced
• Implement any necessary modifications to this action's behaviour
• Find ways of ensuring that any changes to a CodelistVersion's state in the backend are immediately reflected in the UI

Defining delivery tasks guidance

Start by tracing the update_code_statuses action and the CodelistVersion state changes, then reproduce the uploaded and search-created codelist sequences described in #3206. Compare backend changes with the UI state and determine the expected orphan-code behaviour before implementing and verifying the required changes.