feat(registry): remote-refresh Codex client model catalog

[sususu98]

Summary

• refresh codex_client_models.json from the shared models repository alongside models.json
• validate remote catalogs and atomically keep the current embedded or last-known-good snapshot when refreshes fail
• reload Codex client templates by catalog revision, including Home mode where model IDs still come from Home
• bake the validated Codex catalog into CI, Docker, and release builds

Validation

• go test ./...
• go test -race ./internal/registry ./sdk/api/handlers/openai
• go vet ./cmd/server ./cmd/fetch_codex_models ./cmd/validate_codex_models ./internal/registry ./internal/api ./sdk/api/handlers/openai
• go build -o test-output ./cmd/server && rm test-output
• bash -n .github/scripts/refresh-model-catalogs.sh
• actionlint on the changed workflows
• validated the current router-for-me/models Codex client catalog

[gemini-code-assist]

Code Review

This pull request introduces dynamic fetching, validation, and reloading of the Codex client model catalog (codex_client_models.json). It adds a background updater, a dedicated validation command, and updates the server and API handlers to reload templates when the catalog revision changes. The review feedback suggests two key improvements: first, avoid discarding successfully read catalog data if resp.Body.Close() returns an error; second, optimize template loading concurrency by replacing the exclusive sync.Mutex with a sync.RWMutex and implementing a double-checked locking pattern to prevent lock contention on /v1/models requests.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Discarding the successfully fetched and read catalog data solely because resp.Body.Close() returned an error is overly strict. Transport-level errors during connection teardown can occur even when the payload has been fully and correctly read. It is safer to log the close error and proceed with the validated data.

		if errClose != nil {
			log.Debugf("Codex client models response close failed for %s: %v", sourceURL, errClose)
		}

[gemini-code-assist]

Using a sync.Mutex forces an exclusive lock on every call to /v1/models (via loadCodexClientModelTemplatesSnapshot), even when the templates are already loaded and the revision has not changed. Under high concurrency, this can lead to lock contention. Consider using a sync.RWMutex to allow concurrent read access for the common case.

Suggested change

	codexClientModelTemplatesMu sync.Mutex
	codexClientModelTemplatesMu sync.RWMutex

[gemini-code-assist]

With codexClientModelTemplatesMu upgraded to a sync.RWMutex, we can implement a double-checked locking pattern. This allows concurrent requests to read the cached templates using a read lock (RLock), completely avoiding exclusive lock contention when the revision has not changed.

func loadCodexClientModelTemplatesSnapshot(raw []byte, revision uint64) (map[string]map[string]any, map[string]any, error) {
	codexClientModelTemplatesMu.RLock()
	if codexClientModelTemplatesLoaded && codexClientModelTemplatesRevision == revision {
		templates, defaultTemplate, err := codexClientModelTemplates, codexClientDefaultTemplate, codexClientModelTemplatesErr
		codexClientModelTemplatesMu.RUnlock()
		return templates, defaultTemplate, err
	}
	codexClientModelTemplatesMu.RUnlock()

	codexClientModelTemplatesMu.Lock()
	defer codexClientModelTemplatesMu.Unlock()
	if codexClientModelTemplatesLoaded && codexClientModelTemplatesRevision == revision {
		return codexClientModelTemplates, codexClientDefaultTemplate, codexClientModelTemplatesErr
	}