Support provider configuration extensions from custom registry api.json

What feature would you like to see?

Please support provider-level configuration extensions in custom registry api.json files and persist them into config.toml when importing or refreshing a custom provider.

Currently, custom registry providers are parsed into a fixed shape containing only id, name, api, type, env, and models. Other provider-level fields are discarded by toProviderEntry(). The refresh path then removes and recreates the provider using only type, baseUrl, apiKey, and source.

As a result, supported provider settings such as custom_headers cannot be supplied by a custom registry, and manually adding them to config.toml is undone on the next registry refresh.

For example:

{
  "example-provider": {
    "id": "example-provider",
    "name": "Example Provider",
    "api": "https://api.example.test/v1",
    "type": "openai",
    "custom_headers": {
      "User-Agent": "example-client/1.0.0",
      "X-Client-Name": "example-client"
    },
    "models": {
      "example-model": {
        "id": "example-model",
        "name": "Example Model"
      }
    }
  }
}

This should produce and retain:

[providers.example-provider.custom_headers]
User-Agent = "example-client/1.0.0"
X-Client-Name = "example-client"

Ideally, this should support TOML-safe provider extensions rather than only custom_headers. This could be implemented through unknown provider-level fields for compatibility and/or an explicit provider_config extension object.

Top-level snake_case keys should be converted to Kimi Code's internal camelCase representation, while nested keys inside opaque values such as custom_headers and custom_body should remain unchanged.

Additional information

The request layer already supports provider customHeaders, and the provider TOML transform already maps customHeaders back to custom_headers. The missing link appears to be the custom registry import and refresh path in packages/oauth/src/custom-registry.ts.

A possible implementation would:

• Preserve validated, TOML-serializable provider extension fields when parsing a registry.
• Apply extensions before authoritative local fields when rebuilding the provider.
• Keep type, baseUrl, apiKey, and source controlled by Kimi Code.
• Prevent registry data from overriding sensitive fields such as api_key, oauth, source, and platform/auth configuration.
• Reject unsafe object keys such as __proto__, prototype, and constructor.
• Ensure both legacy and v2 provider schemas retain validated extension fields.
• Add an end-to-end round-trip test covering import, TOML persistence, reload, and registry refresh.

This would let registry adapters describe provider-specific request options without requiring users to re-edit config.toml after every refresh.

Start in packages/oauth/src/custom-registry.ts and trace the legacy and v2 provider parsing and refresh paths, then compare them with the request layer's customHeaders support and the provider TOML transform. Verify that validated provider extensions survive import, TOML persistence, reload, and registry refresh while protected fields and unsafe keys remain excluded. Add the requested end-to-end round-trip coverage.