Advertise the full Chat model catalog, not just the SDK enum

[0xadvait]

Why

/v1/models and og-veil models were both derived from the SDK's TEE_LLM enum. That enum ships on the SDK's release cadence and lags the network. At the pinned opengradient 1.1.1 it is missing ten models the gateway already serves and the Chat app already offers:

gpt-5.6-luna · gpt-5.6-terra · gpt-5.6-sol · claude-sonnet-5 · claude-opus-5 · claude-fable-5 · gemini-3.6-flash · gemini-3.5-flash-lite · grok-4.5 · grok-4.3

So an agent probing /v1/models never learned they existed. Bumping the SDK doesn't fix it -- 1.1.3 is missing the same ten.

What

veil/models.py, a curated catalog mirroring the Chat app's lib/constants/models.ts: same models, same display names, same order within a provider. Ids are the bare wire names (the gateway is sent claude-opus-5, not anthropic/claude-opus-5) -- matching both the SDK (model.split("/")[1]) and the Chat app (modelToGatewayModel).

The enum is still folded in on top of the catalog, so anything a later SDK adds shows up without an edit here, and nothing that used to be listed can regress. 42 ids advertised before, 59 now, none dropped.

Neither list gates anything: the gateway stays the source of truth for what's routable, and Veil forwards whatever model the agent sends. This is a listing, so it errs toward completeness.

Also in here:

• /v1/models reports the upstream provider as owned_by instead of a flat "opengradient", and keeps superseded ids listed so an agent already configured for one keeps working.
• og-veil models groups by provider with descriptions instead of printing one flat sorted list; --all adds superseded and SDK-only ids.
• og-veil test defaulted to --model gpt-4.1, which is not a model the network serves (the enum has gpt-4.1-nano / -mini / -2025-04-14, no bare gpt-4.1). Now defaults to claude-haiku-4-5, the Chat app's own free-tier default -- cheap, fast, and available on every account.
• README gains a model table, and drops the superseded claude-sonnet-4-6 from its examples.
• Image-generation models are included, grouped separately. They're called through the same /v1/chat/completions endpoint, which is how the Chat app's Image Studio reaches them.

og-veil models

Models available through OpenGradient Veil:

  Anthropic
    claude-haiku-4-5  Fast, low-cost replies for everyday tasks
    claude-sonnet-5   Balanced all-rounder for writing and code
    claude-opus-5     Latest Opus -- top-tier reasoning for complex work
    claude-fable-5    Anthropic's most capable model for demanding work

  OpenAI
    gpt-4.1-nano   Cheapest option for simple tasks
    gpt-5-mini     Fast and affordable for daily use
    gpt-5          Powerful all-rounder, previous generation
    gpt-5.6-luna   Latest GPT model for fast everyday work
    gpt-5.6-terra  Latest GPT model with strong reasoning at balanced cost
    gpt-5.6-sol    Most capable latest GPT model
  ...

Testing

make check and make test both clean. New tests/test_models.py covers the invariants that matter: ids are bare, the catalog covers the ten the enum lagged on, and known_model_ids() is a superset of the enum -- so the listing can only ever grow.

Follow-up, not in this PR

Keeping this catalog and the Chat app's in sync is manual. If the tee-gateway grows a model-registry endpoint, both should read from it instead. The opengradient floor is also still >=1.1.1 while 1.1.3 is out; bumping it gains nothing here (the union already covers it) so I left it alone.

[0xadvait]

Follow-up commit, prompted by "what about image and video models?" -- both worth answering in the README rather than leaving implicit.

Image models are in (they were in the first commit): gpt-image-2, gemini-3.1-flash-image, seedream-5.0-lite, seedance-4.5, glm-image, plus three superseded. They belong here because resolveGatewayModel puts the image model id on the same OHTTP /v1/chat/completions request as chat -- identical sealed-and-verified path.

But the guarantee is narrower than the surrounding README implies, so it now says so: generated image bytes ride out-of-band and are not signed. From the SDK's response_content_for_hash:

otherwise it hashes the assistant message text (generated image bytes are excluded -- they ride out-of-band and are not signed)

The request is OHTTP-sealed exactly as a text prompt is, so privacy is unchanged. But X-OpenGradient-Verified: true on an image-generation response attests the exchange, not the pixels. Surfacing image models prominently without saying that would have been an over-claim.

Video models are deliberately out. Chat's Video Studio doesn't run over this path at all:

• lib/api/videoStudio.ts sends to chat-api /api/v1/video over a plain fetch with a Supabase bearer token
• nothing under chat-app's app/api references ohttp or tee
• chat-api holds the fal / BytePlus / Atlas keys and calls those providers directly (provider?: "fal" | "byteplus" | "atlas" -- Veo 3.1, Kling v3 Pro, Seedance 2.0, the Wan 2.x line, Happy Horse)
• the shape is async submit + poll on a statusUrl, not an OpenAI-compatible call

No HPKE sealing, no attestation, no signature anywhere in that chain. Listing those ids in /v1/models would tell an agent to send them down the verified private path when none exists. Making it real is a gateway change -- video generation proxied in-enclave -- not a veil change. The README now states the absence and the reason.