Action running status overrides critical status

Expected behavior:

No statuses override higher priority refresh statuses (https://canonical-charm-refresh.readthedocs-hosted.com/latest/user-experience/status/#app, https://canonical-charm-refresh.readthedocs-hosted.com/latest/user-experience/status/#unit-higher-priority), which contain critical information about the refresh status and the next action the user should take

For example, if the refresh is incompatible or a pre-refresh check failed, the user's next action should be to rollback. Overriding the status that instructs them to rollback increases the likelihood that they take a different action or take no action, would could cause data loss or downtime

Actual behavior:

Action running statuses override higher priority refresh statuses
https://github.com/canonical/data-platform-helpers/blob/e224d04d67480b8c33336d3f82c5cc4f374dbced/data_platform_helpers/advanced_statuses/handler.py#L110-L112
https://github.com/canonical/data-platform-helpers/blob/e224d04d67480b8c33336d3f82c5cc4f374dbced/data_platform_helpers/advanced_statuses/handler.py#L150-L154

From my understanding, this deviates from the agreement reached in DA147
> In some cases where there is a critical status i.e. upgrade related statuses. We permit the status to overwrite the entire status and use the full 120 characters available. While this breaks the UX it provides necessary functionality for critical statues.

https://docs.google.com/document/d/1SV11ct-flQkc5BOYOeXgmPeglL8bVs-mDVkGjG20K48/edit?tab=t.0

Start in data_platform_helpers/advanced_statuses/handler.py at the cited lines 110-112 and 150-154, then read the linked refresh-status guidance and DA147 agreement. Trace how action-running statuses are selected relative to critical refresh statuses. Done means critical statuses such as incompatible refreshes or failed pre-refresh checks remain visible and continue to instruct the required next action.

Written by the indexing model from the issue text.