qmi_proc is not loading from QMI_CONFIG if no config file is provided

Description

It turns out that after turning default QMI conf selection behaviour in qmi.start to "None means None", the qmi_proc calls do not seem to load QMI_CONFIG as the second default option anymore. This has happened at least on two different environments of which one in connection with uv run qmi_proc.... In that case QMI_CONFIG was provided in .env file which is referred to with the UV_ENV_FILE environment parameter, so it should be present in the virtual env as well. As this used to work we should figure out if the changed default behaviour of qmi.start should be reverted, and we simply accept the slightly illogical "None is not always None", or we want to solve it some other way.

It could be that the problem is only while running with uv run, which should be confirmed. Then it would mean that the QMI_CONFIG is not read properly at the import-time of the qmi.context_singleton module (for some reason), but perhaps execution-time it would work. If it is defined through .env, it definitely should work at least in the latter case. And in principle also in the former case, but for now we just hypothesize that it doesn't work for some reason.

Possible solutions are:
0) Revert "None means None" logic change.

1. Refresh QMI_CONFIG in context_singleton.py in create_config_from_file such that when called with config_file = "" (which is default if the value is not filled at qmi.start) as follows:

    # Try first to see if input is given or QMI_CONFIG is set
    if config_file == "":
        config_file = QMI_CONFIG or os.getenv("QMI_CONFIG")

2. Refresh QMI_CONFIG in proc.py in case --config argument was not used (i.e. args.config = None) at execution-time in the run function:

config_file = args.config or os.getenv("QMI_CONFIG")
    qmi.start("proc_mgr", config_file=config_file, console_loglevel="WARNING")

The options 1) and 2) should re-check the QMI_CONFIG value at dynamic execution-time. Option 0) would be the least preferred option, unless it is the only way to get it to work again as before if running with uv run.

Actions

Create a unit-test that starts a process with qmi_proc using a specific test-"qmi.conf". The QMI_CONFIG should be set to point to this "qmi.conf"file. Then in the unit-test we try running get the status of the process with qmi_proc without arguments, so that if it fails to find the "qmi.conf" described by QMI_CONFIG, it fails. Then test the possible solutions and see if the unit-test then passes.

If it turns out that the test always passes, we need to introduce uv as a dependency in our optional dependencies and then install it for the unit-test and test running the qmi_proc with uv run.

Files to modify

• tests.core.test_context_singleton_config_file_input OR tests.tools.test_proc
• tests/core/qmi.conf (possibly, or write/delete at the test)
• qmi.core.context_singleton OR
• qmi.tools.proc
• CHANGELOG.md

Acceptance criteria

The QMI_CONFIG should be used, as before (if set), when running qmi_proc commands without config argument.

Start with tests.core.test_context_singleton_config_file_input or tests.tools.test_proc and reproduce qmi_proc without a config argument while QMI_CONFIG points to tests/core/qmi.conf. Compare the behavior of qmi.core.context_singleton and qmi.tools.proc, including the uv run case described in the issue. Done means the test confirms QMI_CONFIG is used and the relevant CHANGELOG.md entry is updated.