[deepratna-awale]

Summary

Resolves #1790.

The log file was hardcoded to Debug and the console to Trace, so users couldn't reduce how much gets written. appsettings.json and environment variables don't help either, because ConfigureLogging() calls LoadConfiguration(...) right after LoadConfigurationFromSection(Config) and replaces those rules.

This adds a Log Level option (Trace / Debug / Info / Warn / Error) under Settings > System Settings. It defaults to Info.

Changes

• AppLogLevel enum and a Settings.LogLevel property, defaulting to Settings.DefaultLogLevel (Info). Existing settings files without the key also get Info.
• The file and console rules start at the default level, so messages logged before settings load match it.
• AppLogLevelApplier sets the minimum level on the catch-all (*) rules that write to the log file and console, unwrapping the async wrappers. Rules for specific loggers (System.*, Microsoft.*, OpenIddict.* and the trace-suppressed types) and the debug log-window target are left alone.
• The level is applied when settings load and again whenever it changes, through RegisterPropertyChangedHandler, so no restart is needed.
• Settings page dropdown plus Label_LogLevel and Label_LogLevel_Description strings.

Testing

• New AppLogLevelApplierTests: every level is applied to the file and console rules, other rules stay unchanged, and a null config is a no-op. These pass along with the existing LogFileTargetTests.
• Ran the app headless on Linux with settings.json set to each of Trace, Debug, Info and Warn, and with no LogLevel key. app.log and the console contained only messages at or above the chosen level. With no key, the level was Info.

Notes for reviewers

• Log rotation is unchanged. app.log is already archived on each launch, with the 9 most recent sessions kept.
• Users who relied on Debug lines in default logs for bug reports will need to switch the setting to Debug.
• Much of the volume in [Feature Request] Option to change the Log Level #1790 likely comes from ComfyClient.HandleTextMessage, which logs every websocket message type it doesn't handle at Warn with the full JSON payload (execution_start, execution_cached, executed, progress_state, execution_success, and custom-node broadcasts). A fix for that is ready as a follow-up PR once this one lands.