Admin option to choose which built-in AI models are offered to users

[xsloba]

Use case: As a deployment admin I want to offer a provider without offering every one of its models. Today CF_AI_GATEWAY_PROVIDERS is the only lever, and it's provider-granular: enabling cloudflare means offering every Workers AI suggested model, and the built-ins can't be deleted (deleteModel refuses them, by design). Orgs often need finer policy than that — e.g. "GLM yes, Kimi no", or the exact case already noted in the SUGGESTED_MODELS TODO in workshop-shared/api.ts:

// TODO: Include Fable -- but we need an admin option to disable it, since many orgs don't allow it for ZDR reasons.

Proposal: admin-curated visibility for built-in AI Gateway models, following the existing disabledGatekeepers / disabledResources pattern (everything enabled by default; the admin UI opts models out):

• AdminConfig.disabledAiModels: string[] — model ids, persisted in the AdminSettings DO and mirrored to KV like the rest of the config.
• A disabled model is hidden from listModels(), refused by getChatContext() / setPreferredModel(), and can't be re-added via addModel() (in AI Gateway mode a custom model routes through the platform gateway anyway, so allowing that would undo the disable). User-added custom models and the internal quick model are unaffected.
• AdminApi.setAiModelEnabled(modelId, enabled) + AdminSettingsView.aiModels (the catalog with enabled state, never hidden from admins so entries can be re-enabled).
• A small "AI models" tab in /admin with a toggle per built-in model, mirroring the Gatekeepers tab interaction.

This also composes with the Anthropic TODO above: Claude models could ship in SUGGESTED_MODELS and ZDR-restricted orgs would just switch them off.

Working reference: I have this implemented and passing the backend test suite (282 tests) on a branch, ~230 lines across 8 files, in case it's useful as a starting point or just as a concreteness check: https://github.com/xsloba/cloudflare-os/tree/feature/admin-model-visibility (diff vs main)

Per CONTRIBUTING.md I'm not opening this as a PR — happy to adjust the approach or contribute it whichever way suits you, or simply to see it land in whatever form you prefer.

Open questions I hit while writing it:

1. Should an existing chat pinned to a since-disabled model fail hard (current behavior in my branch: refuse with "disabled by administrator") or silently fall back to the deployment default?
2. Is per-model curation the right altitude, or would you rather see an allowlist env var (CF_AI_GATEWAY_MODELS) so it stays deployment-controlled like auth config? I went with /admin because model curation feels like runtime policy (same tier as connector availability), not a trust boundary.