The CLI bootstrap loads the configuration but never runs the config upgrade hooks, so a configuration file created by an older Picard version is used (and can be written back) without being migrated to the current schema.

picard/cli/_bootstrap.py:minimal_init() calls setup_config() but does not call run_config_upgrades(). The GUI run run_config_upgrades() after loading the config; the CLI path does not.

Steps to Reproduce
==================
1. Create a config file with an old version, e.g. {{old.ini }}containing:
   [application]
   version=2.0.0
   [setting]
   some_option=1
2. Run any config-loading CLI subcommand against it, e.g.: picard-cli --config-file old.ini profiles list
3. Inspect {{old.ini }}afterwards.

Expected Result
===============
The config is migrated to the current version, exactly like the GUI does at startup. The [application] version is updated and any value conversions defined by the upgrade hooks are applied.

Actual Result
=============
The config version stays at 2.0.0; no upgrade hooks run. Verified: after minimal_init() the config version remained 2.0.0 while PICARD_VERSION was 3.0.0.rc3; calling run_config_upgrades() on the same config correctly upgraded it to 3.0.0.rc3.

Additional Notes
================
Some upgrade hooks are interactive (they may show a Qt dialog to ask the user a question; merge_va_file_naming is the only current example). The CLI is headless and must not block on such a dialog, so the fix must run the upgrade pass non-interactively.