--refresh-rate is ignored when a saved configuration exists

[amakeenk]

Step 1: Describe your environment

• OS: ALT Linux
• s-tui versions tested: 1.1.4 and 1.5.0
• Installation method: distribution package

Step 2: Describe the problem

The --refresh-rate / -r command-line option is ignored when the user has previously saved a refresh rate in the s-tui configuration.

The option was introduced in #196 to allow setting the refresh rate at launch, including for automated workflows. However, its value is currently overwritten by ~/.config/s-tui/s-tui.conf.

Step 3: Reproduce the problem

1. Start s-tui.

2. Open Visual options.

3. Set Refresh to 5.

4. Select Save settings and quit.

5. Run:

   s-tui --refresh-rate 1

Observed result

The refresh rate remains 5 seconds, as stored in the configuration file.

Expected result

The explicitly supplied command-line value should take precedence, so the refresh rate should be 1 second.

The expected precedence is:

built-in default < saved configuration < command-line argument

Root cause

GraphController.__init__() initially assigns the command-line value:

self.refresh_rate = args.refresh_rate

It then calls _load_config(), which unconditionally overwrites it when the configuration contains GraphControl.refresh:

self.refresh_rate = str(self.conf.getfloat("GraphControl", "refresh"))

The parser also uses "2.0" as the argument default, so the application cannot distinguish between an omitted option and an explicit --refresh-rate 2.0.

The temperature threshold option already implements the expected CLI-over-config precedence.

Suggested fix

Use None as the argparse default to represent an omitted option, and apply values in this order:

1. Initialize the built-in default (2.0).
2. Load the saved configuration.
3. If args.refresh_rate is not None, apply it last.

Simply moving the existing assignment after _load_config() would not be sufficient because the current argparse default would then overwrite the saved configuration even when the option was omitted.

Suggested test cases:

• no configuration and no -r: use 2.0;
• saved configuration and no -r: use the saved value;
• saved configuration plus -r 1: use 1;
• saved configuration plus explicit -r 2.0: use 2.0.

Downstream report: https://bugzilla.altlinux.org/48524