[Bug]: Routed models inherit native template context_window when /models omits context metadata #992

Summary

Routed models can inherit the first native Codex catalog entry's context_window when the upstream provider /models response contains only model IDs and no context-window metadata.

This makes a relay model appear as 372000 even though 372000 belongs to the native GPT-5.6 template, not to the relay provider.

Reproduction

Configure an OpenAI-compatible openai-responses provider whose /models response returns rows like:

{"data":[{"id":"<model-id>"}]}

with no context_length, context_size, max_model_len, max_context_length, or nested metadata limits.

Set:

"providerContextCaps": {
  "<provider-name>": 950000
}

After catalog sync, the generated catalog contains:

{
  "slug": "<provider-name>/<model-id>",
  "context_window": 372000,
  "max_context_window": 372000,
  "auto_compact_token_limit": 334800
}

The same behavior occurs for other relay providers that do not return context metadata.

Observed code path

• findNativeTemplate() selects the first bare native entry with base_instructions.
• deriveEntry() deep-clones that template for routed provider/model entries.
• applyProviderConfigHints() applies providerContextCaps only when the CatalogModel already has a valid contextWindow; an unknown window remains undefined.
• applyCatalogModelMetadata() only overwrites the cloned context_window when model.contextWindow exists.
• The cloned native context_window therefore survives into the routed catalog entry.

Relevant files:

• src/codex/catalog/provider-fetch.ts
• src/codex/catalog/sync.ts
• src/codex/catalog/parsing.ts

Related issue: #485 discusses missing relay-provider model capability metadata, but this report focuses on the native-template metadata leakage and the resulting incorrect 372000 value.

Expected behavior

A routed entry should not inherit model-specific context metadata from the native template. When upstream metadata is missing, the implementation should use an explicit provider/model fallback if configured, or a clearly documented conservative default. providerContextCaps should either be applied as the documented fallback for unknown windows or the UI should clearly state that it only caps already-known windows.

Local verification

A local patch that clears context_window, max_context_window, and auto_compact_token_limit from routed template clones, and uses the enabled provider cap as the fallback when discovery has no context metadata, passes the catalog regression tests and TypeScript check.