refactor(_model_config): componentize model config, split store into mixins, unify API key management

[keyboardstaff]

1. Extract model-field.html component to consolidate all model form fields, supporting store / inline API key modes and providerFallback / apiBaseFallback fallback logic; removes duplicated CSS across files.
2. Split store into api-keys-mixin.js (key CRUD, reveal, persistence) and switcher-mixin.js (switching, preset override, tab utilities — including new getActivePreset() / getActiveModels()), composed into model-config-store.js via spread; public $store.modelConfig API is fully preserved.
3. Remove 3 redundant local state objects from api-keys.html; inputs bind directly to $store.modelConfig.apiKeyValues[provider], dirty tracking consolidates to $store.modelConfig.apiKeyDirty as the single source of truth.
4. Merge save and resetToDefault monkey-patches into a single installSettingsHooks(context, config) method with JSDoc; reduces config.html x-init from ~10 lines of inline JS to a single call.

Bug Fix

• Root cause: After saving an API key via Settings → Configure Models, clicking Settings Save would overwrite that key with an empty string — Settings loads with api_keys[provider] as "", and the backend writes it directly to .env, clobbering the key that was just saved.
• Fix: Add _syncApiKeysToSettingsStore() — after a successful API key save, sync the corresponding provider's value in the Settings store to API_KEY_PLACEHOLDER ("************"); the backend skips writing when it encounters this placeholder, preventing the overwrite.
• Unified entry point: All entry points (Settings / Plugins / Presets) now use setApiKeyValue() + persistAllDirtyApiKeys() instead of inline x-model bindings inside presets; saveGlobalPresets strips api_key fields before saving.

[nicolasleao]

Nice refactor overall. Consolidating the repeated model UI and splitting store concerns makes a lot of sense.

There's a potential regression around the preset Utility Model fallback behavior:

1. In model-field.html, the store-backed API key branch uses model.provider directly instead of the fallback-aware provider (providerFallback / _prov). For utility presets with no explicit provider, the API key reveal/status/save path may stop following the intended fallback to the main model provider.

2. The shared provider <select> no longer appears to include an empty option, which may make it impossible to set the Utility preset provider back to “blank = use fallback/default behavior.”

I don't have full context here, so please point out if I'm wrong

[keyboardstaff]

Nice refactor overall. Consolidating the repeated model UI and splitting store concerns makes a lot of sense.

There's a potential regression around the preset Utility Model fallback behavior:

1. In model-field.html, the store-backed API key branch uses model.provider directly instead of the fallback-aware provider (providerFallback / _prov). For utility presets with no explicit provider, the API key reveal/status/save path may stop following the intended fallback to the main model provider.
2. The shared provider <select> no longer appears to include an empty option, which may make it impossible to set the Utility preset provider back to “blank = use fallback/default behavior.”

I don't have full context here, so please point out if I'm wrong

Thanks for the feedback, the issue has been fixed.