Subtle bug: model.variants can be unintentionally overwritten when ProviderTransform.variants() returns {} #12169

Bug Description

There's a subtle bug in provider.ts where model.variants is unconditionally overwritten with the result of ProviderTransform.variants(model) before merging with user config variants.

The Issue

In the provider state initialization (around line 925), the code does:

model.variants = mapValues(ProviderTransform.variants(model), (v) => v)

// Then tries to merge with config
const configVariants = configProvider?.models?.[modelID]?.variants
if (configVariants && model.variants) {
  const merged = mergeDeep(model.variants, configVariants)
  model.variants = mapValues(
    pickBy(merged, (v) => !v.disabled),
    (v) => omit(v, ["disabled"]),
  )
}

The problem is that ProviderTransform.variants() returns {} for models like kimi, deepseek, minimax, etc. (lines 331-341 in transform.ts). This means:

1. model.variants is first set to {}
2. Then the code attempts to merge with configVariants

Why This Is Subtle

Currently, this doesn't cause visible issues because:

• The merge with configVariants happens immediately after
• For most models, ProviderTransform.variants() returns non-empty variants

However, the subtle bug emerges in this scenario:

If a user defines custom variants in config AND those variants happen to have the same name as a built-in variant that ProviderTransform.variants() would return (if it weren't empty), the merge order and the fact that we first overwrite then merge could lead to unexpected precedence issues.

More importantly, if configVariants lookup fails or is undefined (which can happen in certain config loading edge cases), the user-defined variants from an earlier processing step would be lost entirely.

Current Workaround

The code happens to work now because:

1. For built-in providers, models go through initial processing where variants are set
2. The second loop then overwrites and re-merges
3. For kimi models, ProviderTransform returns {} so the merge just uses configVariants

Suggested Fix

Instead of overwriting then conditionally merging, we should merge directly:

const baseVariants = ProviderTransform.variants(model)
const mergedVariants = mergeDeep(baseVariants, model.variants ?? {})
model.variants = mapValues(
  pickBy(mergedVariants, (v) => !v.disabled),
  (v) => omit(v, ["disabled"]),
)

This ensures:

1. User-defined variants from config always take precedence
2. No data loss if ProviderTransform returns {}
3. Cleaner, more predictable behavior

Impact

This is a low-severity bug that doesn't affect current functionality but could cause issues if:

• Future changes modify the config loading order
• Custom provider configs become more complex
• Models start having overlapping variant names between built-in and user-defined

I've submitted PR #XXX with a fix.